openstreetmap / iD

🆔 The easy-to-use OpenStreetMap editor in JavaScript.
https://www.openstreetmap.org/edit?editor=id
ISC License
3.3k stars 1.2k forks source link

Support of IGN arial imagery (France) #3420

Closed bagage closed 7 years ago

bagage commented 7 years ago

As stated to latest SOTM France, IGN local authority allowed use of their aerial imagery for openstreetmap contributions. It provides an alternative to Bing in France, with locally (much) better quality and/or up-to-date data. Integration for JOSM was done by Christian Quest through a TMS proxy: http://proxy-ign.openstreetmap.fr/bdortho/{zoom}/{x}/{y}.jpg (authenticated by user-agent). However this TMS is restricted to the use of a referer (hence the question/issue #3197). It has been 4 months since JOSM (working!) integration, I would really like (as other French iD users :smile: ) to see it available in iD as well. We are currently stuck on this referer issue so here are my questions:

Thanks!

bhousel commented 7 years ago

Sorry, aside from what I already mentioned in #3197, I don't have any ideas on how to accomplish this..

tyrasd commented 7 years ago

Is support of referer in iD possible?

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way. What the browser decides to send depends on a number of factors, such as a user's privacy settings, installed privacy/ad-blocker addons and whether the web page and requested assets are on the same server/subdomain and/or use the same protocol (https or http).

If a web app could change the content of the referrer header, the effect would be the same as a public token (any other non-iD web page could fake the iD referrer).

PS: Are you aware that a malicious desktop application could fake the user agent it sends in order to illicitly scrape the imagery? Isn't that also basically the same as a public token (or less: a token could be easily revoked and replaced by a new one, while the user agent of JOSM will basically always stay the same)? :confused:

//cc @cquest //cc @althio

tyrasd commented 7 years ago

Some people in OP's linked forum thread seem to complain that this ticket was closed too quickly (see auto-translation below), so let's reopen it.

I am surprised at the speed with which closed bhousel this issue ... : Shock: As he says himself, he has no idea to solve the problem (so there is a problem! ) but closing the end it leaves anyone the ability to have an idea. Strange behavior! :?

On topic: I think what @bhousel wanted to say is that there's no easy way to implement such a usage-restriction really securely with the current code infrastructure. I would recommend talking to the provider of the imagery again and ask if using a public token would be OK for them. IMHO, if they are OK with the referrer-based check used with JOSM, they should also be OK with using a token-based system for iD (because it provides about the same level of security against scrapers, and also because it has been used as a solution in similar cases in the past, for example the geoimage imagery in Austria), but I'm certainly not the one to decide. If a token-based system isn't going to work out, one would have to implement some elaborate system where users log-in (maybe with their OSM account) in order to authenticate themselves against the imagery source or proxy, which would require changes to both iD and the server. And I also don't know how to accomplish this easily – ideas pull requests are very welcome!

bhousel commented 7 years ago

AFAIK, that's simply impossible to achieve in a web application: The referrer header is set by the browser itself and a web page can't influence the presence, absence or content of it in any way.

☝️ This is why the ticket is closed - you restated the issue very well. It's closed simply because there is nothing we can do from iD to change how browsers fetch images.

I agree that the French OSM community should continue to work with IGN to open up their imagery, or find a way to proxy it themselves that satisfies the upstream requirements.

althio commented 7 years ago

French OSM community should [...] find a way to proxy it themselves that satisfies the upstream requirements.

That is the chosen path, eg see https://github.com/osmlab/editor-layer-index/issues/194