I'm probably missing something obvious. My apologizes if it's actually the case.
I don't know if we can trust that, but in the facebook example previously given, they're talking about OAuth 2.0. 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. 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. 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. I hope this makes sense. Pierre On Sat, Nov 19, 2011 at 8:28 PM, Tom Hughes <[email protected]> wrote: > On 19/11/11 19:15, Pierre GIRAUD wrote: > >> My concerns now are to avoid the authorization multiplication ie. to >> prevent users from being asked several times for a permission they >> already gave. > > Well just carry on using the same access token that you got the first time. > You only get proliferation if you keep restarting the process by getting a > new request token, authorising it, and then converting it to an access > token. > >> Shouldn't there be a mechanism that verifies that the application has >> already been authorized? > > Yes - your possession of the access token and it's secret is how you prove > that you have been authorized. If you hang on to those and reuse them then > we will continue to allow you access. > >> In this application [1] described here [2], once the user has >> authorized the application, he can log in again and again without >> being asked for permission unless he goes to the profile and revokes >> the authorization intentionaly. >> [1] http://facebook-auth.appspot.com/ >> [2] >> http://facebook-python-library.docs-library.appspot.com/facebook-python/examples/oauth.html > > Facebook is not directly comparable because it doesn't use OAuth as far as I > know. It uses the proprietary Facebook Connect protocol. > > I don't know the details of how the Facebook protocol works, but it is > certainly possible to do what you want with OAuth. > > Tom > > -- > Tom Hughes ([email protected]) > http://compton.nu/ > -- ------------------------------------------------------------- | Pierre GIRAUD | http://pierrelebricoleur.blogspot.com | http://www.flickr.com/photos/pierregiraud ------------------------------------------------------------- _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
