I'm trying to make a HTTP GET request in javascript to a rest API from within an iframe.
The iframe is sandboxed, but it has the allow-scripts attribute set, and the API I'm calling is enabled to allow all origins, so CORS shouldn't be a problem.
I've recreated the scenario with a minimal code sample here:
http://plnkr.co/edit/jrchvxFXQQDqs2Fv
If you go to that page and preview the page with any modern browser (Chrome, Edge, etc.) it works correctly.
But if you do that with Internet Explorer 11, the call fails. On the javascript console, we get this generic network error:
but the weird thing is: the call is actually running correctly. In fact, if we check the network tab, we can see it being performed and returming 200:
Am I doing something wrong here, or is this just the usual IE being IE?
I found that we need to add allow-same-origin to make it work in IE.
By default sandbox forces the “different origin” policy for the iframe. In other words, it makes the browser to treat the iframe as coming from another origin, even if its src points to the same site. allow-same-origin removes this feature. So I think it fails in IE at first because it doesn't meet the same-origin policy.
As for the difference between IE and other browsers, I think that's due to the different policy design in different browsers.
I also find a thread about the issue and there's some useful information, you could also refer to it for more information.
Related
I am trying to open a webview iframe. Problem is that Internet explorer (11) doesn't set cookie for webpage loaded in iframe. It works fine in chrome, firefox and even in Edge.
Internet Explorer supports a cookie-restricting privacy feature called P3P. Web developers often get tripped up by it because no other browser implements the P3P standard.
To get IE to accept cookies from your server in a 3rd-party context (or to get IE to resend a previously-set cookie to your server when it is accessed in a 3rd-party context), you must declare the privacy policy that governs how your cookies will be used. That declaration takes the form of a P3P header on the HTTP response (or, less commonly, a META tag with the same content).
For more detailed information, please refer link below will be helpful to understand and solve the issue.
Reference:
A Quick Look at P3P
I am currently creating a new version of a website that uses a third party service that can only be accessed through an iframe. This service exclusively works on Internet Explorer (not on Edge) in compatibility mode (and with certain security options set), while the new website is developed with more modern browsers in mind (mainly Chrome).
Is there any way to insert an iframe into the page, and make the iframe load its content with IE's engine even though the page containing it has been loaded in Chrome?
I'm not talking about the "user agent" field in the request header (as discussed in this question), I'm talking about rendering the response with a different browser's engine.
No, there isn't.
Not even if the computer has Internet Explorer installed.
iframes dont have a support for browser option selection. so this requirement cant be fulfilled. there is one plugin called ietab but its only for development purpose, which runes ie in chrome browser.
I'm trying to store a value on another domain using an iframe (actually, I'm using the xauth library at http://xauth.org/info/). However, when I try to store anything using Chrome, it comes back with "QUOTA_EXCEEDED_ERR: DOM Exception 22", which I've come to recognize as an access error. I've mocked up a couple of very simple pages below to duplicate the effect:
File 1.html:
<html>
<head/>
<iframe src='http://127.0.0.1/2.html' />
</html>
File 2.html:
<html>
<head/>
<script>
console.log(localStorage);
localStorage.setItem('test', '123');
</script>
</html>
If I place both of these on my local server and access localhost/1.html it embeds a frame from 127.0.0.1 (which Chrome considers a separate domain), and I get the same access error as above. At a guess, it looks like even though I'm embedding an iframe from another domain, and the script inside that iframe references the localStorage for that domain properly (as I can see with the console.log(localStorage) line), the permissions for writing to localStorage are coming from the top page's domain.
In short, it looks like no iframe can write to localStorage in Chrome. Does anybody know if there's a way around this particular security "feature"? Or am I doing something wrong?
The problem only occurs when third-party cookies are disabled. Newer versions of Firefox and Opera are also blocking it. In IE and Edge it is still possible although third-party cookies are disabled. If the localStorage would not be blocked in the iframe, a web tracker could simply include a iframe, read the cookie, send it to the parent script, and then send it to the server.
The reason why this is not blocked in IE and Edge is that these browser allow websites to send third-party cookies, which were previously set as first-party cookies, to the server although third-party cookies are blocked. For example, if a user visits facebook on a regular basis, he gets first-party cookies from facebook. When he then visits other websites with facebook's share button, facebook can track him although third-party cookies are disabled. I really do not know why IE and Edge do not block third-party cookie sending, but I would not use these browsers anyway.
The errors the browsers show when third-party cookies are disabled:
Chrome and Opera: Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
Firefox: SecurityError: The operation is insecure.
IE and Edge: No error, access to localStorage in iframe is possible although third-party cookies are disabled.
So in conclusion, it is not possible to bypass this security feature (in Chrome, Firefox, Opera) and this is good in order to ensure users' privacy.
This is an old post, but if someone else see it- you can use postMessage
https://stackoverflow.com/a/40469196/4836581
Well, localStorage is domain-based and there is no reason for your example code to fail. What it actually does is to set the test item to 123 for 127.0.0.1 whereas it will leave the localhost localStorage empty.
This might not be the answer to your initial problem of QUOTA_EXCEEDED_ERR, but just try to switch to private browsing on Chrome (Ctrl+Shift+N) to see if you still have the error. Without further information on what you were initially doing, I can't tell much but I believe that quota exceeded means what it means...
And I think Chrome's quota is 2.5mb unlike FF which has 5mb of localStorage quota.
Notice how Firebug can access the DOM of cross domain iframes and even allow you to modify them? I'm wondering if there is an firefox addon extension or a config setting that will allow a page on our intranet to do this.
Longer explanation:
I have a two "kiosks" in our reception area that the public can use. As we're running in kiosk mode (fullscreen, no chrome), I have created a small web application consisting of a menu and an IFRAME. The menu allows users to browse to approved sites and also perform actions like printing. It also gloms onto requests for popup windows and instead overlays them in a modal iframe rather than allowing the browser and OS chrome to be exposed - breaking the "kiosk" experience.
Obviously, this works perfectly on anything internal because it's all on the same domain. It gets trickier when browsing external sites because the XSS protection kicks in and you can't see the DOM inside the IFRAME.
I have also tried using a web-based proxy server on the same domain (PHProxy for example), which works okay, but there are horrible edge cases where it doesn't work - a big one is the CAPTCHA on our website forms. So that's pretty much not an option for me.
Basically I think the only solution that will work for me is to modify the browser in some way using a security setting or an addon. Any ideas?
Thanks guys very much for you time and consideration. It is VERY much appreciated.
--Iain
There is a way for unpriviledged JavaScript code (loaded from a web page) to request more privileges in Firefox. This is an old, non standard API that prompts the user for permission and if accepted allows the JavaScript to do things normal JavaScript cannot. One of these things is to bypass Same Origin Policy.
Sample code:
try {
// ask user for permission
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
} catch (e) {
// user refused permission
alert('Permission "UniversalBrowserRead" was denied.');
}
//Should now be capable of bypassing same origin policy if user accepted
Since the kiosk browser does not restart (I suppose) very often, the dialog just has to be accepted once. Not sure this is the most elegant solution but might work, at least for now (the API is old and might disappear).
Here is a link for more details: http://www.mozilla.org/projects/security/components/signed-scripts.html#privs-list
While looking for the exact privilege name I found this page about Security Policies in Firefox. This would be a much nicer solution. I have never used it, so I cannot give more info, but here is the link, might be a good place to start looking:
http://www.mozilla.org/projects/security/components/ConfigPolicy.html
Hope this helps!
I found an addon called CrossDomain. The addon hasn't yet been updated for newer versions of Firefox. In the end, I solved this whole problem by writing an HTA and using the internet explorer rendering engine - which made my IT manager happy :). Here is the link to CrossDomain in case this helps someone one day. Thank you everyone for your submissions.
https://addons.mozilla.org/en-US/firefox/addon/13004/
Why not use Greasemonkey, it will allow you to run your script on any page.
I'm using Facebook Connect in my app. I have it working pretty well, but in the Safari Error console, I'm seeing errors like this:
Unsafe JavaScript attempt to access frame with URL http://...#... from frame with URL http://www.connect.facebook.com/extern/login_status.phpapi_key=..&extern=2&channel=http...xd_receiver.htm.
Domains, protocols and ports must match.
The app seems to function ok, though we are seeing periodic hangs and other bad behavior from Safari. When I run other Facebook Connect apps, I sometimes see this error too, so I don't think this is a problem with our implementation. Is it safe to ignore this warning?
Safari's cross frame security is tighter than other browsers, I have done specific try/catch wrappers to handle these cases, if it otherwise works, great.
Either way, would post the bug upstream as olliej suggests.
It means you're attempting some form of cross origin access, which is unsafe -- while it may seem benign it's probably worth trying to find out why you're hitting it, if you use the nightlies or the Safari4 beta you can use the debugger in the web inspector, and make it break on all exceptions, which will let you see when it's actually attempting the cross-origin access.
As for the hangs, if you can find some kind of reduced testcase it would be great if you could file them at http://bugs.webkit.org
This is a red herring. The request still goes through and everything is working properly but WebKit still logs an exception.