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
Related
I'm developing a Firefox add-on which does block the malicious URLs. The problem is that sometimes Firefox render its own deceptive warning page and sometime it allows the extension to render its own warning page.
How can I bypass the deceptive page warning programmatically?
The above behaviour is working fine on Chrome.
Abdul Basit.
The easy way is with the privacy WebExtension API, here the documentation on the Mozilla Developer Network (MDN):
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/privacy
Access and modify various privacy-related browser settings. To use the
privacy API, you must have the "privacy" API permission.
You can already use services.safeBrowsingEnabled for Chrome, Opera, Edge, but Firefox not yet.
You can play around with the request status code 400, because it is related to the deceptive request routing.
Good luck.
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.
Upon submitting a form from my website to third-party website, the HTTP post request will trigger downloading a file. This works fine with Firefox and Chrome. However, Internet Explorer 7/8 security setting prevent downloading the file by saying:
file download blocked - To help protect your security Internet Explorer blocked this site from downloading files to your computer
I know this is a issue with CORS, which has been resolved in IE 9+, FF and Chrome. right now I need to support IE 8 bypassing the security setting. Is there any workaround I can do here? So basically what CORE does is to add a HTTP header request so that the server knows this is a request from different domain.
IF you search for the CORS solution for IE 7/8 you will have to use a XDomainRequest. For IE 10+ browsers they have changed it to use XMLHTTPRequest. Have a look at following link to get a idea about CORS using XDR.
http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx
http://amareswar.blogspot.com/2012/06/cors-issues-with-ie9-and-workarounds.html
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.
I followed the example: http://arunranga.com/examples/access-control/credentialedRequest.html
from this page: http://arunranga.com/examples/access-control/
The example work in Firefox, but not Safari, anyone have tried in implementing CORS cross domain cookie handling, and being success in Safari?
Thanks.
Safari also blocks cookies from sites that haven't been visited directly. You can see in the security settings. It's default setting is Accept cookies: "Only from sites I visit".
This will help get you started.
Setting cross-domain cookies in Safari
I have jsonp working in safari using methods in the above link. So assumed that the cookie would work in the CORS context, but at this stage it doesn't seem to be working. Also, changing the security setting seems to have no effect.
Safari might demand a stricter set of headers to be returned?
This sounds like a Safari bug. I just verified that cross-domain cookies aren't being set in Safari. Cross-domain cookies are working in Chrome, so this may be fixed in WebKit and the latest hasn't made it to Safari yet. I haven't seen a Safari or WebKit bug report about this.
I encountered this with API/UI apps on different subdomains of Heroku, like my-api.herokuapp.com and my-ui.herokuapp.com, session cookie was set for my-api.herokuapp.com. Even visiting my-api.herokuapp.com didn't seem to help Safari in this case with its default 'Only from sites I visit' policy #23inhouse mentioned: http://content.screencast.com/users/artemv/folders/Jing/media/4dfc08d7-0e9c-483f-a272-bbe91549ea95/00000759.png.
However, Safari worked just fine when we assigned a custom domain to these apps and it became my-api.mydomain.com and my-ui.mydomain.com - so it looks like Safari has particularly low trust to popular hosters' subdomains. No direct visit to my-api.mydomain.com was needed in this case.