We developed new file action for our web-app, it works fine when using chrome or Firefox but on IE we have problems, when trying to understand the issues we noticed that when the message goes to our web-app it doesn't send any cookies including the session cookie although the web-app sends set-cookie header.
why is it happens?
OK, we found the problem, apparently when using iframes in IE cookies are blocked as IE refers to Iframes as third party app, to unblock cookies we should to add privacy policy to the headers using P3P header.
good place to read about is - Cookie blocked/not saved in IFRAME in Internet Explorer.
This sounds like a possible bug on our end. Can you email us at API AT box.com with specific information about the request that's being sent as well as which version of IE you're using?
Related
I am trying to make a CORS request with credentials(Cookies attached) and Chrome is not attaching the Cookie to my request. I have set the cookie to a sub-domain of the existing page and i could observe it is set successfully from the Cookie manager.
I do not have this problem with Chrome 78th version(latest version). But for the previous versions, I have this problem(I have checked 75 and 77). As well as i do not have any problem with other major browsers also. They also attach cookies without a problem.(I have tested my code with Firefox, IE, Opera and Edge)
This how I have set the Cookie from external service end.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None;');
Complete sample code base can be found in following links:
External service - https://github.com/bhanukayapa/cors-backend.git
Front-end application - https://github.com/bhanukayapa/cors-angular-frontend.git
Can someone please explain the root cause for this problem? I checked Chrome release notes also. I could not find and bug fix or improvement related to this. Thanks in advance.
If setting SameSite=None this must be paired with Secure. e.g.
res.setHeader('Set-Cookie','cdn-token=exp3header_same-site-none; domain=.local.com; path=/; SameSite=None; Secure');
We recently discovered an interesting bug in newly released Chrome v.39.
It just crashed with standard "Aw Snap!" message on every page with an iframe if that iframe loads a page with Content-Security-Policy HTTP header. This blocked out web-site because we host some third-party ads.
From what i found the "Content-Security-Policy" header is a W3C standard and Google Chrome used to support in between v.25 and v.38 releases. But from now they don't.
Does anyone know a nice practical solution for this issue? Is there a way to prevent Chrome from crashing without this workaround?
If you want support Chrome 39/40, I found that adding the protocol in front of domain would prevent the crash (It's not required in CSP 2.0, but it's better than crash).
If you want support Chrome 41, it didn't crash even without protocol name.
Hope this helps.
In order to fix the issue we had to add a logic that sends X-Content-Security-Policy to all but IE and Content-Security-Policy to IE only. This is ugly code/solution but at least it stopped crashing.
This example to load a url in an iframe works. However when I change url to something like http://www.yahoo.com the iframe doesn't load antyhing
Here is an example side by side.
In Network tab of developer tools for Chrome, I see that request to Yahoo was cancelled. In FF it doesn't give any errors, just doesn't return any content. IE9 gives a message that It cannot display this content.
This happens in Chrome, FF and IE9 (I haven't tested previous versions of IE).
That is because Yahoo itself prevents this from happening.
It has been noted here: https://stackoverflow.com/a/9013722/476786
To see for yourself, try setting the source to http://www.google.com/ which won't work as well, but then try http://www.bbc.co.uk/ and that will work.
Possibly works as described here: https://stackoverflow.com/a/2896705/476786 using X-FRAME-OPTIONS
If the site hosting the webpage forces the use of a secure HTTPS connection, some browsers (chrome for sure) will require that all network resources use HTTPS as well.
Basically if your site forces HTTPS, try setting src="https://yahoo.com"
This won't solve OP's answer directly due to it being a limitation of Yahoo itself, but other people viewing this page might be experiencing this issue as a result of this (I was).
I'm making an offline webpage that automatically logs into an online website.
The website uses ssl (https) and to login it uses a form (post variables)
The problem I'm encountering is the following:
The site only accepts my offline form, when I open the online login page first.
This is because the website uses (server-side) sessions which are made when opening the first page. (The purpose of the session is to detect a time-out)
When I first open the online website and then run my offline page everything works fine.
So I need to make my offline webpage open the online website before posting the form automatically.
I tryed this with an iframe, but this doesn't work in internet explorer, as it is a https website. (It does work in Chrome, firefox,...)
I was wondering if Ajax could send a https page request before posting my form. But I guess not as it is https.
Does anybody know a method to send a https page request just like the browser does, but without showing it's output? Afterward I can automatically submit my form.
Thanks in advance!
Internet Explorer treats iframes from other domains as third party content, and uses a separate set of security policies for them. The security zone settings are also in effect between file:/// "local machine"/"offline" webpages and "internet"/"online" webpages. Cookies are usually blocked from third party content (depending on your settings), which means that the unique session key set in the cookies won't be saved. Without this key, the site you are trying to log in to will "forget" your session/login.
Cross-domain AJAX request are also affected by security zones and cross-domain policies, but the settings may differ between IE versions.
There are ways around the limitations, using P3P policies, if you control the target web page. Cookie blocked/not saved in IFRAME in Internet Explorer shows how. But, if you do own the web page, it would be better to enable or implement your own "remember me" feature.
In your case, depending on if you are the only one to use your offline autologin webpage, perhaps allowing third party cookies in Internet Explorer will help. See Options > Privacy > Allow all cookies (or in a similar). This will allow others (mostly ad companies) to track you all over the internet though.
If the purpose for your autologin page is testing, rather than actually using the browser as a human being, perhaps you can automate both logging in and testing?
Trying to copy a cookie from second.com to first.com, with full control of both domains.
Previously an iFrame was used, however this is not able to work across all browsers as it touched on 'third-party cookies' which are hard to implement and impossible in Safari and Chrome.
The new approach uses a SCRIPT tag pointing to second.com and included in the HEAD of first.com. The server-side script is actually a piece of Java which reads the cookies sent with the request (the cookies from second.com) and the JavaScript returned executes on first.com and essentially duplicates the cookie here. This is working great in all browsers except IE, where IE appears to not be sending the second.com cookies with SCRIPT request, so the Java is not able to pickup the cookie value from second.com.
This is surely to do with IE security settings as when I put privacy to the lowest level it is working, but my question is why are the cookies being blocked at all? I thought the SCRIPT tag was not subject to the same origin policy (that AJAX and other technologies have to comply with).
Any solution to this without heading down the P3P privacy policy route?
It's definitely IE security settings, if you're attempting this you'll need to set a P3P compact privacy policy on the page which sets the cookie on first.com, even before you've reached second.com