[panel] mapbox doesn't load when using a token with url restrictions about kirby-locator HOT 8 CLOSED

Good to hear you found a pragmatic workaround (on a side note: it has always baffled me that browsers accept such change to the global referrerpolicy after the load event; but it's apparently evaluated at the time of the click event).

As of these results, I concur with your assessment. Good to learn that there was yet one more scenario (scripts loading stuff into the panel via API) that we hadn't yet come across in those earlier discussions. I'm hoping to run a few more experiments when I find some spare time – just out of curiosity to thoroughly "x-ray" all aspects of this – and would ping you if I find any surprise leads …not putting my hopes up, though 🙂

from kirby-locator.

Hi! I just added a bit of context/history about that strict referrer policy of the Kirby panel in a comment on that issue in the Kirby core repo.

I'm not able to try this out right now and this is based on a really quick glance at the plugin's code, but I think this might actually be possible to resolve by changing line

An element-specific referrerpolicy overrides the page-wide policy for this element and all its children, hence it should (?!) also be inherited by any image elements of the map? My apologies in advance if I'm overlooking something obvious – we did this for an iframe over at the kirby-embed plugin (Github issue) but I haven't actually ever tried this for JS-generated elements.

from kirby-locator.

I didn't know that referrerpolicy is inherited by child elements, actually I thought that it would be only valid on img / a / iframe / script / etc... elements. I'll try this out and let you know :)

from kirby-locator.

Are you sure it worked for the other plugin?
According to my tests done now, it doesn't really seem to be inherited, at least not in Chrome and MDN only says

You can specify the referrerpolicy attribute on <a>, <area>, <img>, <iframe>, <script>, or <link> elements to set referrer policies for individual requests

from kirby-locator.

You are actually right! I did some deep digging into the W3C spec where that inheritance rule is defined in the usual cryptic way so it appears not to be working on a <div> the way I had previously understood. The other plugin was a different scenario, as it was a simple iframe-based embed; that worked flawlessly.

I, too, just ran some tests and got the same results (i.e. none). There would still be the option to apply a referrerpolicy attribute to the script tag importing the script; see https://html.spec.whatwg.org/multipage/scripting.html#attr-script-referrerpolicy for reference. How this applies and/or can be tweaked in Vue or the Kirby Panel, I don't know – that's a whole over dimension of inheritances etc. And I'm not even sure where we'd have to put this.

This is a really intriguing case, but right now I'm a bit on the edge of my technical skills to experiment further… I still want to believe that it should be possible to set a policy for something I embed on a page (here: a JS library that loads map tiles) which is then observed by the included script (i.e. Leaflet). But maybe I'm just chasing a 🌈?

from kirby-locator.

In this case the refer(r)er needs to be sent on the single image tiles, so even if we would include leaflet with a referrerpolicy attribute, the images created by leaflet wouldn't automatically "inherit" the policy. The only clean way to solve this would be leaflet setting the policy on their image tags (like they did here: Leaflet/Leaflet@f1f4e05), but as already mentioned we would have to wait for them to release version 1.8.0, but that milestone has "no due date" and is 65% done.

Anyway, one strategy could still be "just wait until 1.8.0". In the meantime I've "fixed" my issue with a plugin that does this:

document.querySelector("meta[name=referrer]").content = "strict-origin-when-cross-origin";

from kirby-locator.

So, after some more reading and experimentation, I would indeed conclude that there is no way to selectively relax the referrer policy for these map requests. As you pointed out, the policy for scripts' fetch requests are not inherited from any elements but from the document meta or (with lower priority) the HTTP header. The suggested feature for Leaflet 1.8.0 will be the only way to change this in a "clean" manner.

Your creative workaround solution however made me think whether this "hack" couldn't be turned into an integrated feature – and after a bit of digging I discovered the right events for the job: if #47 should prove reliable and stable, I see this as the best stopgap solution to solve this. It would allow to maintain the Kirby panel's strict privacy-by-default philosophy while still allowing to embed libraries like Leaflet that do not support explicit fetch request policies.

from kirby-locator.

Many thanks to both of you for looking into it ! 🙏 I have merged #47 and will revert once 1.8.0 is out (92% now).

from kirby-locator.