New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GDPR] Export function on osm.org and OAuth token #1848

Open
mmd-osm opened this Issue May 3, 2018 · 2 comments

Comments

Projects
None yet
2 participants
@mmd-osm
Contributor

mmd-osm commented May 3, 2018

Apologies, this is early and possibly a bit premature. It just crossed my mind, and I thought lets create an issue for it before I forget about it again.

Steps to reproduce:

  1. Log on to osm.org
  2. Go to https://www.openstreetmap.org/export
  3. Select an area of interest
  4. Export (and check HTTP headers)

My expectation would be, that the export contains the full meta data, as I'm a logged on user (this will be the future scenario, once https://wiki.openstreetmap.org/wiki/GDPR/Affected_Services is in place).

However, unlike the /map call in iD editor or JOSM, the export function doesn't provide an OAuth token to the /map call (HTTP Header: Authorization OAuth oauth_consumer_key= ...), which basically tells CGimap that I'm an unauthenticated user.

Would it be possible to issue a /map call similar to the way it is implemented in iD, and include the OAuth token as well?

(it's ok to put this issue in some GDPR queue right now, and evaluate it at later point in time along with other GDPR requirements).

@tomhughes

This comment has been minimized.

Member

tomhughes commented May 3, 2018

I think it just redirects doesn't it? So no, it's not possible to authenticate it.

@mmd-osm

This comment has been minimized.

Contributor

mmd-osm commented May 3, 2018

Yes, that's correct. To make that happen, one option could be to replace the redirect by some Javascript code for an authenticated download, and then writing the result to a file. As the download is limited to 50'000 nodes, chances to kill a browser this way are limited. As a bonus, we could do some error handling in the Javascript code and show a nice message. This would replace the generic browser error a user gets today ("Page unavailable").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment