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
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
On domain www.maindomain.com I have the following page
<iframe src='https://www.otherdomain.com/somepage.php' />
The IIS webserver that hosts www.otherdomain.com has been properly configured with the necessary cross-origin headers.
In fact, there's no issue with any of the major browsers, desktop and mobile.
However, on Safari and on Safari only, the connection is rejected as insecure.
Is there a known workaround?
Thanks
Team,
I am working on Angular JS application. When I want to test the app, I used to just launch the application directly into the browser from file system. The url would be like
file:///Users/easwar/AngularApp/index.html
When I need to launch the app in Chrome, I need to open the browser from terminal using the below command
open -a Google\ Chrome --args --disable-web-security -–allow-file-access-from-files
to avoid the below error.
"XMLHttpRequest cannot load , Cross origin requests are
only supported for protocol schemes: http, data, chrome,
chrome-extension, https, chrome-extension-resource."
But surprisingly in Safari the app works fine without doing anything like this.
I would like to find what is the difference between these browser behaviors? Why its working in Safari and its not working in Chrome without a tweak?
In short: google chrome doesn't like local cross calls.
More found here: Cross origin requests are only supported for HTTP but it's not cross-domain .
It's Googles privacy and security policy: they try to avoid as much risks as possible, and local file calling seems to be one of them.
Read more on cross origin requests and how they're handled in Google Chrome here: https://developer.chrome.com/extensions/xhr
If you don't want to use those console commands, you might want to look for a webserver to host it (or a local webserver).
I have a webpage that embeds a flash widget that sends AJAX POSTs. I use PHP to interpret these on the server.
The problem is that Internet Explorer doesn't send the "Cookie" HTTP header from the requests generated in the Flash, so I'm unable to pick up my PHP session on the server.
Chrome and FF do send the Cookie header from inside the flash.
I've tried the P3P headers and browser security settings changes.
Does anyone know if this is possible within IE? I can't change the flash, so would have to be a browser setting, or ideally, some HTTP change...
If its a problem with IE you can probably fix it for yourself by installing the newest version of IE and Flash on your computer. Other people are probably going to have trouble with it however. I really don't know what you are talking about with "Cookie" header but I don't see why that would stop you from handling a request if it is getting sent. If you wanted to post the code that is handling the request that would probably be helpful.
In reality, you probably shouldn't be using a Flash solution to handle your ajax requests.
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.