Here's an other good example. http://www.jaisenmathai.com/sign_in_with_twitter/start.php Even better, the authorization step is only required once, unless you manually revoke permission on the twitter account settings.
Pierre On Sun, Nov 20, 2011 at 12:10 AM, Pierre GIRAUD <[email protected]> wrote: > 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 > ------------------------------------------------------------- > -- ------------------------------------------------------------- | Pierre GIRAUD | http://pierrelebricoleur.blogspot.com | http://www.flickr.com/photos/pierregiraud ------------------------------------------------------------- _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
