I am trying to make cross-domain requests with Safari on Windows. My Safari version is 5.1.2.
This is a classical question. I read in many places that Chrome and Safari allows cross domain requests as long as Server responds with the followin header in the response
Access-Control-Allow-Origin: *
I have read this post.
How to allow cross-domain requests in Safari?
and many others on the stackoverflow site too.
However, none of them answers my question.
I am having problems with Chrome AND Safari doing cross-domain AJAX requests even though I am sending the necessary header back from the server.
I finally ran Chrome with "--disable-web-security". Then it worked.
My questions:
1) What do I do with Safari? Do I use a similar command line argument?
2) More importantly, can I someone please tell me whether cross-domain functionality is allowed in Chrome and Safari by default as long as server responds with the header or do I have to make sure that
a) server responds with a header
AND
b) browser is started with a proper argument.
I found the problem. Reading more about CORS helped html5rocks.com/en/tutorials/cors. I realized that my requests were triggering preflight requests (OPTIONS) and the server was not set up to handle these requests properly. The reason it was causing preflight requests was because I was using JQuery and it was adding a custom header into my requests. I modified my code to prevent addition of this extra header and my requests no longer needed preflight requests. Now I do not have to disable web security and it works fine.
Related
Modern browsers support CORS handily. If CORS-aided cross-origin-XHR is sent to CORS-ignorant site, the XHR succeeds in no question.
Does it expose more vulnerability in this regard? How to strictly enforce Same Origin Policy on today's browsers?
Take a look at how preflight requests work in CORS. The CORS preflight request protects servers from unauthorized requests by first asking the server whether it is ok to make the cross-origin request. If the server says "yes", the browser continues with the request. Otherwise the request fails.
Note that there are certain types of requests that don't need preflight requests. However, these requests were already possible even before CORS. For example, a simple GET request does not need a preflight, but a GET can already be made with a script tag.
You can learn more about CORS and the preflight here: http://www.html5rocks.com/en/tutorials/cors/
I have developed a web application that makes ajax requests to a web service on a server in a different domain from the server that hosts the web app.
I have configured the web service to do a pre-flight check to set the necessary headers to allow a cross domain request.
In the web app I am using a JQuery client to access the web service. I have set the properties on the Jquery command to allow cross domain access.
$.support.cors = true;
In Chrome this all works fine. In IE9, however the cross domain behavior is only partially successful. All get requests work. But post requests with a content-type of application/json fail because IE9 refuses to make post requests with any content-type except text/html. IE9 switches the content-type on the request and the request fails on the server with a 400 bad request.
I had read that with IE10 the cross domain request would work as in Chrome. But after just testing this, I find that IE10 has the same behavior as IE9. The browser will not set the content-type to application/json. So post requests fail.
Does anyone know whether it is possible in IE10 to do cross domain post requests with other content-types than text/html. This makes writing web apps that do anything more than display data extremely difficult.
Are there other settings I need to make on the Jquery request? Or in the service pre-flight?
What does your $.ajax() call look like? You could try adding data: 'json' to your JQuery call in order to force the data type to be json. You also shouldn't need to set $.support.cors = true;, JQuery should figure this out for you (but its ok to leave it in for now).
I do have the content type param set data: 'json'.
Chrome honors this but IE switches to text/html. I had read that this was a know issue in IE9 and below but that IE10 would be using the same ajax implementation as Chrome, but this is apparently not the case.
I'm working on extensions for Firefox and Chrome. The data used by my extensions is mostly generated from ajax requests. The type of data being returned is private, so it needs to be secure. My server supports https and the ajax calls are being sent to an https domain. Information is being sent back and forth, and the extensions are working correctly.
My questions are:
Do the extensions actually make secure connections with the server, or is this considered the same as cross domain posting, sending a request from a http page to a https page?
Am I putting my users' information at more risk during the transfers than if the user were to access the information directly from an https web page in the browser?
Thanks in advance!
The browser absolutely makes a secure connection when you use HTTPS. Certainly, a browser would never downgrade the security of your connection without telling you: it will either complete the request as written or it throw some sort of error if it is not possible.
Extensions for both Chrome and Firefox are permitted to make cross-domain AJAX requests. In Chrome, you simply need to supply the protocol/name of the host as a permission in your manifest.json. In Firefox, I think you may need to use Components.classes to get a cross-domain requester, as described in the MDN page for Using XMLHttpRequest, but I'm not 100% sure about that. Just try doing a normal request and see if it succeeds; if not, use the Components.classes solution.
I'm trying to make a secure authentication POST request from an HTTP domain to an HTTPS domain using Ajax. For Firefox, Chrome and other modern browsers, it's possible to do this using a CORS request. Unfortunately IE8 and IE9 don't support CORS, which makes this type of authentication difficult.
In point 7 of XDomainRequest - Restrictions, Limitations and Workarounds, Eric Law mentions a workaround for IE's limitation on HTTP-to-HTTPS cross-domain requests. However, while the workaround demo works for IE9, it doesn't work for IE8.
Is there any other workaround for IE8 to send a cross-domain POST request from an HTTP domain to an HTTPS domain?
Note that sending a JSONP GET request probably won't due, because passing user credentials in the authentication request's URL parameters means that the credentials would be recorded in web server logs files. If those logs were compromised, then users' credentials would be compromised too.
The demo doesn't work because IE8 doesn't support the addEventListener method for adding event listeners. Instead, the demo should use the attachEvent method.
I have verified that it works in IE8 if the correct attachEvent method is used.
I've just come across a problem relating to IE that there seems to be virtually no documentation about on the 'Net - only a few people asking similar questions.
When I use jQuery (1.4.2) to send a POST request to my server (to which the server responds by sending JSON data), I occasionally get XHR 408 errors (meaning that the server timed out while waiting for the client to finish its request), and (less frequently), XHR 12152 errors (I don't know what these signify). There does not seem to be a pattern to this.
This only occurs in IE (version 8 - I haven't tried other versions, though I can confirm that the problem occurs on two different installations). Safari and Opera seem fine.
This doesn't seem to be a problem with GET requests.
If anyone has any thoughts on the matter, I'd be very grateful.
When you see IE returning things in status that clearly aren't HTTP status codes, they're actually Windows error numbers, typically from WinInet.
12152 ERROR_HTTP_INVALID_SERVER_RESPONSE would seem to confirm the 408's implication that there's a low-level HTTP-syntax problem between your browser and the server. Traditionally this has been a problem with the ActiveX implementation of XMLHttpRequest and keep-alives in HTTPS, but the exact cause is rather murky.
You could perhaps try having the server set Connection: close on XMLHttpRequests that come from IE, see if that helps? This will affect performance, unfortunately.
I solved it by adding "Connection: close" to ajax header also.
There is no need to add "Connection: close" to the response header from the server.
I have tested firing 1,000 requests.