at the moment I have an issue regarding implementing an iFrame into my ionic app. Everything is working if I open the Page, where the iFrame is embeded, on Android. But if I open the page on iOS I get an error in my console which says:
Blocked a frame with origin "http://mywebsite.com" from accessing a frame with origin "file://". The frame requesting has protocol of "http", the frame being accessed has a protocol of "file". Protocols must match.
How can I fix this issue? Do I have to make changes on the Page which I'm trying to embed or do I have to change something within the app?
Best regards and thanks
Related
With the new permission request API introduced in Safari on iOS 13, I get this error when doing the permission request on a cross origin iframe:
Call to requestPermission() failed, reason: Source frame did not have the same security origin as the main page.
I could not find any corresponding Feature-Policy to add to the iframe "allow" property: neither 'accelerometer' or 'gyroscope' worked...
Is there a way to allow DeviceOrientationEvent.requestPermission() on cross domain iframe?
The only workaround that worked for me is redirecting through the iframed domain once.
So, if you have abc.com and xyz.com is an iframe under abc.com, while landing to the abc.com, there needs to be an intermediate redirect through xyz.com only for the purpose of setting a blank cookie. Then Safari will allow setting a cookie from iframe for xyz.com.
I'm not sure if there's any other better workaround. However, this worked and served my purpose.
Thanks.
On my site, we create a popup window which that gets redirected to Google authorization, with a RedirectUri back to my site after login specified. In the main window, we check the state of the popup window to determine whether or not a user has already logged in so that we can close this popup window.
Normally, once the user has logged in and the popup has been redirected back to my site, we can access the popup window in the main window. However, starting with the latest version of Chrome (v. 63.0.3239.132), we'll get the following error:
DOMException: Blocked a frame with origin "..." from accessing a cross-origin frame.
This seems related to this Chrome bug, however we aren't calling window.open from an iframe (it gets called from the main site). 63.0.3239.132 was also supposed to introduce a fix for this issue.
I don't always repro this issue: if a user is already logged into their Google account, the main window can access the popup window once the popup gets redirected back to my site. Also, after the initial redirect to Google authorization (to the account selector page), I can navigate the popup window back to my site, at which point the main window will be able to access the popup window once more.
This issue also don't repro in earlier versions of Chrome and other browsers.
I can't fix your problem but I can suggest an alternative way to go about what you are doing.
Rather than accessing the popup window directly from your main page, or the main page from your popup (window.opener), have you considered communicating between these pages (which are both served from your app) by using the browser's sessionStorage?
Your pages/windows will share sessionStorage so one or both can hook into the window.onstorage event to watch for changes made by the other.
https://developer.mozilla.org/en-US/docs/Web/API/WindowEventHandlers/onstorage
I realise that this will require some redevelopment and therefore isn't strictly an answer to your problem, but I hope it is still a useful suggestion.
I was trying to host a web page in the chrome extension popup and was hitting error X-FRAME options set to deny or SAME ORIGIN. As an alternative approach I opened up the page in new chrome browser instance and injected the script into it so that i can send the message from the page to content script and then back to my popup page once the work is done in the new window . UI experience of this approach does not look good and hence wanted to go via Iframe route. My extension has all url permissions in manifest.xml
Can someone suggest the right approach by which we can host a web page in IFRAME in chrome extension popup and get around the deny and SAME ORIGIN. Also will this be correct with respect to security .
I came across this unanswerd blog but seems to me a hack. Hence wanted to get clarity on chromium - extension forum.
Getting around X-Frame-Options DENY in a Chrome extension?
I have a website that uses the Facebook login button and
connect.facebook.net/en_US/all.js
As of friday, I started getting a cross-origin security error when new users were trying to log in.
Uncaught SecurityError: Blocked a frame with origin "https://www.facebook.com" from accessing a frame with origin "http://www.facebook.com". The frame requesting access has a protocol of "https", the frame being accessed has a protocol of "http". Protocols must match.
Instead of redirecting after login, the dialog box just turns to a blank white screen.
This is only happening in Chrome. Everything runs smoothly in Safari and Firefox.
Anyone else experiencing these issues?
Any ideas about a possible fix?
I have a dev site set up that's running under a fake HTTPS, it has a certificate however Chrome says its invalid because of the domain. My real site has a real certificate however, and I'm wondering if that HTTPS connection will break because of some insecure content on my page.
I'm using Brightcove as a 3rd party video host and when using their embed code, I get these types of errors in the Chrome developer console on my dev site:
The page at https://my.website.com/ displayed insecure content from http://c.brightcove.com/crossdomain.xml.
If I deploy the development version to my live site, will it break the HTTPS seal in the address bar of browsers? HTTPS is very important for my customers so I'd rather not deploy it and just see what happens.
Unfortunately Brightcove doesn't have "true" HTTPS support, it's either get these errors or the video doesn't work. :/
Also, the video is being loaded via JavaScript if that matters.
Thanks!
If you include content from insecure sources (http), the seal will break. it's still safe but it won't be shown as prominent as on a page with only secure content inclusion.