When we send non-simple request to another domain, the preflight request is being send first by the browser. Is it possible to somehow read the body or headers of preflight request responses in javascript?
For example:
fetch('example.com', { method: "DELETE" }).then(handler)
Will trigger a preflight request and if it succeeds, the "handler" function will be able to read a response for our main request. But is there any way to access the preflight request's response?
After looking through the fetch specification, my understanding of the request access is the preflight request will be returned if it had an error, otherwise, the main request will be returned (error or not) and the preflight will go inaccessible. However, I wasn't able to test this, and the specification wasn't the clearest for understanding the behavior of the function.
Edit:
I did some testing with https://test-cors.org, and found that I was wrong. Whenever the CORS request fails, all that you can get is the error object. If the request succeeds, all you get is the final response. The automated preflight request is completely hidden from JS, so as #Titus said in a comment, the only way to get the preflight response is to manually configure and send an OPTIONS request.
Related
I am trying to access a Google Apps Script WebAPI from my website using javascript to pass some value and create an excel file and download it through this API.
I tried 2 following way:
Using POST request with $.post.
My values are many. So, at first, I use a POST request with a body is JSON of list values. Browser rejects API response, because of CORS error.
I researched about CORS to understand it. At some topics, I found a solution is the following second way.
Access to XMLHttpRequest at 'https://script.google.com/macros/s/xxxxxxx' from origin 'https://example.com' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
Using GET request with $.getJSON.
I pass JSON of list values to URL parameter and make GET request. It worked fine.
var url = 'https://script.google.com/macros/s/' + api_id + '/exec?' + request_parameter_string;
$.post(url, payload, function(data, textStatus) {
// Do something
}, 'json');
$.getJSON(url, function(json_result) {
// Do something
})
.fail(function() {
// Do something
});
What I do not understand is why? Why it works with getJSON but not work with post?
I think CORS work with both of GET and POST requests. And I checked the response header with Postman. The headers are the same Access-Control-Allow-Origin →*.
I think have something is different inside getJSON and post functions.
*UPDATE: Update POST CORS error message.
GET requests are not bound by CORS we can host images and static files in CDN which is different from the origin and would help in improving the performance by caching and making parallel requests.
Similarly GET is used for serving ads, trackers and analytics from third party domains as well.
More information about Same Origin Policy and GET is at https://security.stackexchange.com/a/16221/9517
How the browsers identify Other HTTP Verbs are allowed for the cross origin request is elaborated # https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
I am using angular 2 for the front end and jersey for the back end. Whenever I am calling any API through angular, It sends a preflight request (OPTIONS request) and then sends the original request.
As we have no control over custom headers for OPTIONS request. We have our filters in the back end which checks the request headers and if it does not contain our certain headers parameters then it rejects the request. So OPTION request gets rejected.
So, Is there any way to stop these preflight requests? Or Is there any way to handle these requests in the backend side?
Please set this "Access-Control-Allow-Origin: *" in header from server side
The CORS specification states that if a HTTP request is considered 'simple', no CORS and/or preflight is needed.
I'm trying to do a HTTP request that appears to have these conditions:
I'm not setting custom HTTP headers.
I'm using a POST method.
I'm using application/x-www-form-urlencoded.
Code sample:
$.ajax({
type: 'POST',
url: 'http://example.org/',
data: {foo: 'bar'}
});
However, when running this, the request is still preflighted with OPTIONS (which fails). Is there something obvious I'm missing?
A few references to simple requests:
https://w3c.github.io/webappsec-cors-for-developers/#cross-origin-send-permissions-simple-safelisted-request
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Simple_requests
CORS restrictions affect all requests going from one domain to another. example: localhost -> example.com. I end up just going to my example.com server-side code and make sure I enable requests from myotherexample.com where I am making calls from. Do this using the CORS header while developing locally
Access-Control-Allow-Origin: *
Another example when you are ready for production
Access-Control-Allow-Origin: https://myotherexample.com
I realized my mistake when re-reading the documentation.
What I am doing is indeed a simple request.
The request was actually being sent to the server without an OPTIONS request and succeeded!
However, I was not allowed to read the response when it came back. So the true difference between simple and non-simple CORS requests is:
For simple requests a preflight is not needed, but the server still needs to respond with CORS headers.
So my options are as follows:
I ignore the error. The request succeeded after all, I just can't read the response.
I implement CORS server-side anyway. In my case I can't, because I don't control the target server.
I use a html form to submit the data, call .submit() on it and target a hidden iFrame.
I proxy the request through a server that I do control.
Future:
I think, but I'm not sure, that the new Fetch API also allows a mode where you can make HTTP requests cross-domain, opt-out of CORS and simply be denied access to the HTTP response. If this is correct, then this would be the ideal way to do this (to me). But I don't know 100% certain if this is indeed how this works.
Here's my situation: I make an ajax post to a server endpoint, and it sends me back some JSON data in response. This JSON response also includes the Set-cookie header.
Does the cookie get set automatically when it's in a response to an ajax request, or do I have to read it out of the headers and do it manually?
(As opposed to the headers being present on the response to a form submit, where I know the browser will be handling the response and its headers on its own, no JS necessarily involved.)
Yes, it gets set automatically. An AJAX request is just an HTTP request. You can send Cookie headers, and receive Set-Cookie Headers normally.
I have a problem with ajax request to Steam.
I want to get price from steam market.
function jPrice(httpToJson) {
$.getJSON(httpToJson, function(data) {
return data.median_price;
});
}
When I call function
jPrice('http://steamcommunity.com/market/priceoverview/?country=US¤cy=1&appid=730&market_hash_name=StatTrak%E2%84%A2%20P250%20%7C%20Steel%20Disruption%20%28Factory%20New%29');
I get an error:
XMLHttpRequest cannot load http://steamcommunity.com/market/priceoverview/?country=US¤cy=1&appid=730&market_hash_name=StatTrak%E2%84%A2%20P250%20%7C%20Steel%20Disruption%20%28Factory%20New%29. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://lоcalhоst:63342' is therefore not allowed access.
I try:
Set php header Access-Control-Allow-Origin to *
JSONP
RESULT -> The same thing (error)!
Maybe someone knows a solution to this problem?
You won't be able to get the results in your browser via ajax request made directly against steamcommunity.com, neither by setting the header Access-Control-Allow-Origin to *, nor by sending a JSONP request.
For this to work, steamcommunity.com should either add CORS headers in the response (the error message you're seing means that they are not there), or format the output to be JSON-P. They didn't do either.
This is a browser restriction, do not allow the content from a different origin to be loaded via ajax. What you need to do is introduce a middle-ware, so have your back-end server to make a request against steamcommunity.com and return the same response, and make the ajax call against you're server. This will work, your back-end is sending the request, and as it is not a browser request, the response will land, than your ajax call will be able to get the response as well since it is issued against the same domain