Open bovine3dom opened 4 years ago
~There's something fishy going on with the /map/
working better than /map/?blahblah
. With the query string the iframe is trying to get to :2016 for some reason.~
I'm not sure that allow-same-origin
should be required for our iframe. Anyway, we can try changing the return from the oembed endpoint and see if wordpress insists on making it "more secure".
Hmm, the :2016 thing has gone away. Maybe a cache issue.
Anyway, we can try changing the return from the oembed endpoint and see if wordpress insists on making it "more secure".
I'm not sure what you're suggesting here. Edit: oh, adding sandbox
to our oembed return, I see. Yeah, I think it will insist on making it more secure. allow-scripts and allow-same-origin means the iframe can edit its own iframe which means it can remove its own sandbox. I think we need to either whitelist ourselves in WordPress, ~as I assume it'll be fine on other sites as it won't have the same origin~ Edit2: Nope, it needs same-origin if I just edit txti.es to add an iframe too. We could host the map on a different domain (e.g. map.cmcaine.co.uk)? Further investigation needed.
:2016 thing has gone away
I have a similar issue across multiple devices (and David) - /map redirects to :8080/map, which isn't real. /map/ works fine. Probably an nginx configuration issue.
Not sure how to fix this issue so for now I've made a plugin for WordPress that whitelists us in src/wordpress-gcvt-plugin.
If we decide to permanently go down that route we should turn off oEmbed discovery as it currently steals links in sites that support it and replaces them with a broken map.
The final (?) hurdle is that WordPress adds
sandbox="allow-scripts"
, which implies noallow-same-origin
, which we currently need as our backend,/api/
, is on the same origin. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox@cmcaine, any ideas?