I assume this issue is not directly Kirby-related, but maybe someone has an idea:
I have built a tiny plugin for Vimeo-previews in the panel which I need for a current project. In order to load and play the videos I am using Vimeo’s own player.js both in the front-end and in the panel.
When I now try to load a private video which is allowed for embeds on a specific domain, the videos successfully load on the front-end but not in the panel, even though I am using almost exactly the same code. A “not embeddable” error is thrown, even though the video definitely is.
My question: Is there anything in the panel code that might interfere with the safelisted domain? I found that another iframe wrapped around the iframe that is being rendered by player.js might cause problems. But that’s not the case in the Kirby panel AFAIK.
This might indeed be related to the panel HTML setting the referrer policy to a strict "same-origin" (see <meta name="referrer" content="same-origin"> in the source).
This is to avoid panel URLs from leaking to third parties: otherwise, clicking on a link to somebody’s website from within the panel page for a yet unpublished or purposely “unlisted” page would leak that page’s URL (as the panel URLs contain the path to the page).
While this is the sensible default, not least for GDPR compliance (unpublished URLs may contain personal data like names), I could imagine that it causes such issues as your Vimeo problem. The referrer policy can also be set by sending the according headers, but I do not know which one takes precedence when both a header and the meta tag are present (I have a hunch that the meta tag would take precedence, so am sceptical can it be overridden by sending the header). Updating the meta attribute with JavaScript after page load probably (better: hopefully) would not affect the browser’s policy setting either. But there’s a few things to try out?
Otherwise the only solution I could think of is to either suggest a reduction of the panel’s referrer policy in core to strict-origin-when-cross-origin (leaking the site’s URL but no page paths; not ideal in my opinion, as it may still allow insight to some) or better to allow for this value to be overriden via config (I believe this would be the best in terms of privacy/security, as site owners could add allowed recipients of referrer data – like vimeo.com in your case – in a granular manner) while otherwise staying in “stealth mode” by default.
Actually, on second thought, since you mention it is your own plugin: if the <iframe> element used in your code to embed the video in the panel, you should be able to set a referrerpolicy="strict-origin-when-cross-origin" (or any other referrer policy, if that is still too tight) on the iframe element. That way, the loosened policy would only apply to the embedded source.
The W3C spec is not specific about precedence, but from a logical point of view, I’d assume that specificity rules apply as they do with similar things: i.e. server header gets overruled by meta tag, gets overruled by attribute on a element…
Thanks so much for diving so deep into this @sebastiangreger , really amazing! Turns out your answer is part of the solution: For my plugin, I switched from using Vimeo’s player.js to requesting an oEmbed via their API, which in turn allows me to send along my own referrer header. This in combination with adding the referrer policy to the iframe as you suggested has just solved this! Thanks a million!
