On Sat, Jun 27, 2009 at 3:17 PM, Tom Hughes<t...@compton.nu> wrote: > Frederik Ramm wrote: >> Is the application required to keep track of which operations are allowed >> with the token and which aren't? I mean, if I am the application and I send >> my user over to OSM to get permission for reading his preferences, and later >> I want to make an edit in the user's name and try to use that same token - >> will this then simply fail, and would I then send the user to OSM again to >> upgrade the token, or would I get a new token then? Or would I always check >> with OSM first wether what I'm about to do is allowed with the token? > > Matt knows more about how it all works than me but you will certainly need > to do something to either upgrade or replace the token.
at the moment there isn't an API to interrogate a token to find out which capabilities it has, but if that's wanted it can be added. the workflow is like this: 1. application developer registers with OSM, and sets up those permissions which their app wants/needs, 2. user uses the app, which uses its credentials to form an OAuth request, 3. user is redirected to OSM where they log in and agree to none, some or all of the permissions the app requested, 4. OSM redirects the user back to the app's "callback" URL, although the app doesn't actually need to close the loop - this can be a static page saying "thanks. you can close this window and return to the app", 5. any call to the API using that token is forbidden if the app didn't request that capability or the user didn't approve it and OK otherwise. 6. the user can revoke that token at any time, including while the app is using it. if you need to "upgrade" a token then you can ask for a new one with different permissions. *or* a better way might be to have multiple tokens for the app (e.g: one token for the API capability, another for GPX). that way the user can approve and revoke them at different times. >> Has there been any discussion, or even consensus, on the lifetime of >> tokens? Will this be left to the user? Will they be valid until revoked? > > They last forever unless explicitly revoked I believe. yep, although it would be pretty simple to have them expire after some time (maybe set by the app) if anyone would find that useful? Frederik Ramm wrote: > Tom Hughes wrote: >>> * allow third party applications to identify an OSM user so that they >>> can, for example, store local preferences under that username? >> >> I'm not sure what you mean by "identify" in this context, but one of >> the permissions an application can ask for is the ability to read and/or >> write to a users preferences (read and write are separate permissions). > > I would want a third-party application to know that whoever they are > talking to is the OSM user so-and-so, that's all - so that the application > can e.g. save application-local preferences for that user without having > to use an extra login/password to that site. yep - you want the "read user preferences" capability. it allows you to read the user preferences and the user details. the OSM display name is part of that and i'm thinking of adding the user ID too, since display name can change. if you want to store the preferences on the OSM server instead (e.g: to allow site independence) then you'll also want the "write user preferences" capability. cheers, matt _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
