maproulette
Store user API token in OSM user preferences
This was brought up in https://github.com/maproulette/maproulette2/issues/476
This would allow third parties to make authenticated MapRoulette API calls on behalf of a MapRoulette user, if that user were to grant access to their API key.
This would require additional permissions for the MapRoulette OAuth application on osm.org: currently we only ask for read permissions on OSM user preferences.
The issue I see with this is that there is no granularity in grants for OSM user preferences. Anytime a user grants read access to their OSM user preferences from any application, the MapRoulette API key would be exposed. This could have unintended consequences if another app would grab the user's MapRoulette API key and started using it to make requests requiring the API key.
Tagging @simonpoole since the idea came up as part of the discussion about Vepucci / MR integration
Hi,
Pouring in on the discussion from the MapComplete-repository and we are struggling with this as well.
The core of MapComplete is user-friendliness and not having to care about technical issues. Having a multi-step process with the manual copying of an API-key is a no-go. (Imagine trying to explain to my mom to:
- Go to MapRoulette
- Go searching into the settings
- Search for some obscure string
- To copy it
- To paste it into the right field in the settings of MC
- ...)
At this point, there even is no settings-view in MapComplete, as 99% of the users use the defaults anyway. (There are settings of course, by they are put on logical locations throughout the application)
Currently, we are thinking about using a dummy-account which all users would silently use if they handle a task.
I feel your pain @pietervdvn .. I hope to cook up a solution for this sooner rather than later.. It's been raised by various people that it hinders integration.
I hope your mom enjoys MapComplete without MapRoulette integration :)
Adding this to 3.11 milestone @jschwarz2030 but still requires some discussion, I think
The key should probably be namespaced, since users can technically run their own instance of MR.
Example:
<preference k="maproulette.org:apikey" v="API_KEY"/>
or
<preference k="apikey:maproulette.org" v="API_KEY"/>
We might want the :<site> to point to the actual api it is for, so maybe apikey:maproulette.org/api/v2 instead of just maproulette.org?
FTR: Vespucci uses maproulette_apikey_v2.
@tsmock I like this suggestion. apikey:maproulette.org/api/v2 would make it descriptive and specific. @simonpoole I would appreciate your thoughts.
Let's stick with @tsmock 's suggestion using underscores so we avoid any complications related to URL encoding and such.
@jschwarz2030 am I correct in saying that this uses the non-namespaced key, aka what Vespucci has been using all along?
In any case while I understand @tsmock sentiment, to be useful a name spaced key would need some convention on how to construct it so that clients could automatically generate it from the maproulette api URL (this could be very trivial naturally).
I had been thinking of something like
<preference k="apikey:maproulette.org/api/v2" v="APIKEY" />
<!-- or -->
<preference k="apikey:https://maproulette.org/api/v2" v="APIKEY" />
Either one trivially allows clients to figure out what service the API key is for, and given the API URL, assuming everything standardizes on one or the other, can be trivially found.
Getting/setting the full preferences isn't an issue. The problem comes from the /api/0.6/user/preferences/[KEY] PUT and GET calls. If we want to support either one of those, then we have to worry about URL encoding. For the current API URL (mapillary.com/api/v2), . and / are issues. It would probably help if we could either URL encode the key or use a POST (application/x-www-form-urlencoded) keys. That should probably be a feature request/PR on openstreetmap/openstreetmap-website.
I'll look into why they don't appear to do a URL decode for the [KEY].
For now, maproulette_apikey_v2 will work, but I don't think it will be good long-term.
@jschwarz2030 am I correct in saying that this uses the non-namespaced key, aka what Vespucci has been using all along?
In any case while I understand @tsmock sentiment, to be useful a name spaced key would need some convention on how to construct it so that clients could automatically generate it from the maproulette api URL (this could be very trivial naturally).
Yes I decided to use maproulette_apikey_v2, for reasons that @tsmock stated above. As far as I can tell, a URL path as a key won't work due to the restrictions of the OSM preferences API.
I've opened a PR for the website so that URL encoded keys can be passed as the [KEY] value.
https://github.com/openstreetmap/openstreetmap-website/pull/3787
Update: this feature is currently in production. Please let me know if you run into any problems.
The API key is stored in the maproulette_apikey_v2 key in the OSM user preferences (api/0.6/user/preferences)