[josm-dev] shocking - unsecure password sending!

[Karl Guggisberg]

> josm will already have the unauthorised request token when it sends the user to log in. it then has to make a final 
> call to swap the newly authorised request token for an access token.
I've missed this important detail, this changes my picture in that copy/pasting is indeed not necessary. 

-- Karl 

-----Ursprüngliche Nachricht-----
Von: Frederik Ramm [mailto:frederik at remote.org] 
Gesendet: Mittwoch, 7. Oktober 2009 16:58
An: karl.guggisberg at guggis.ch
Cc: josm-dev at openstreetmap.org
Betreff: Re: AW: [josm-dev] shocking - unsecure password sending!

Hi,

Karl Guggisberg wrote:
>> Probably right although I'm sure a way can be found to save the user from having to cut+paste the token.
> I'm afraid, it can't. If JOSM was a web application, it would be part 
> of the OAuth protocol that the OSM website "calls back" JOSM with the request token. For a java rich client this is isn't possible.

I quizzed Matt Amos about this and he said:

no, the callback isn't necessary. it's a good idea, if josm isn't going to use it, to have it direct to a "thanks, you can close this window" static page, though. the app already knows the token, as it negotiated it with the server. the only reason for the callback is to help web-apps stay stateless.

for example, if the app associates the token with session 1, but the user doesn't log in immediately or signs up and gets redirected via their email client for email validation then when they follow the callback it could be in session 2. so the callback is just there to help tie the sessions together.

josm will already have the unauthorised request token when it sends the user to log in. it then has to make a final call to swap the newly authorised request token for an access token.

Bye
Frederik