On 19/11/11 23:10, Pierre GIRAUD wrote:
I don't know if we can trust that, but in the facebook example
previously given, they're talking about OAuth 2.0.
Which we don't support yet.
Actually it's a bit more complicated than that, because it might work,
bit I haven't tested it at all so I'm not going to claim that we support it.
Anyway, my problem is that I cannot really cache the access token and
the corresponding secret. My application is a web application. Users
connect via a browser. My application doesn't deal with any
authentication itself. I cannot therefore store (in a database) any
token for a user because I don't know which user is actually connected
before he logs in using the OSM OAuth service.
You are misunderstanding what OAuth is. It is not a system for allowing
a user to authenticate to your website (yes I know that twitter abuse it
in that way but it is explicitly not what OAuth is intended for) rather
it is a way for a user to grant your website permission to do things on
our site.
Well I'm already storing the username (which is the only information I
need actually) in a cookie so that they don't have to re-log in if
they close their browser.
But this cookie expires when it is 2 weeks old. I don't really want a
cookie that never expires. I can't tell why. When the cookie expires,
the user is then anonymous and is invited to log in using OSM
authorization before he can use the application.
I can of course save the information about the token in a cookie as
well, but I cannot ensure that the cookie will not be deleted. If so,
the user will be asked for permission again. Which means a new entry
in the list of authorized applications in the user's oauth settings on
the OSM site.
This is a basic limitation of OAuth and isn't something I can do
anything about.
Please read the OAuth specifications if you want to know about how it
works and what it's limitations are.
An other good example, is the "log on twitter" on yfrog. As far as I
know, twitter uses OAuth. If you go to yfrog.com, you can "sign in"
with twitter. Then you can sign out and sign in again. Each time, you
sign in, you're asked to authorize the application to access your
twitter data. However, if you go to your twitter account settings. In
the application tab, you can see an entry for yfrog (and only one).
Even more, it's the first one you accepted.
As with Facebook, I have no knowledge of how Twitter use OAuth or
achieve the effects that they do beyond knowing that it is well known
that they abuse OAuth as an authentication mechanism.
I can only think of two ways to achieve the effect you use with OAuth
though. One would be to delete old access tokens when a new one was
created but that would be undesirable for us as, for example, a user
with multiple JOSM installs would than authorizing one would cut the
others off.
The other way would be to simply hide the existence of multiple access
tokens for an application and only present a single entry in the UI for
an application regardless of how many tokens it had. The downside of
that would be that revoking access would have to revoke all the current
tokens.
Tom
--
Tom Hughes ([email protected])
http://compton.nu/
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
