I'am sure it execute controllers once, but execute $http request twice.So every operation to my DB does twice!
The requests cross domain,and I set 'Access-Control-Allow-Origin:*'.
I get OPTIONS request before every normal request,but I guess the OPTIONS request have nothing to do with the TWICE problem.
This is preflight CORS requests. Notice that first request is OPTIONS and second one is POST.
This happens when you send request to other domain
Very good explanation: CORS - What is the motivation behind introducing preflight requests?
Related
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.
A software that i'm using(https://camlytics.com/) sends a request to a webhook whenever a particular event occurs, now i want to process that request but the problem is that the request is sent with the following headers as empty
content-length
content-type
Due to this reason my node code completely ignores the request. I have verified that the request is actually being sent via creating a webhook # webhook.site.
I fail to understand if webhook.site can show and process that request, why cant node do it? the code easily processes all other get requests.
Would appreciate if someone could either
help me process the request as in make it accessible via the code
if somone with experience on camlytics help me configure it in such a way that i can configure the headers of the request.
I have tried this on serverless azure function which is supposed to trigger for all HTTP requests but event that doesnt trigger, neither does it trigger on my local NODE server.
This is the request details that webhook.site shows me
Camlytics webhooks seem to work OK if you add Content-Type application/json to the Headers properties box for the HTTP Response node.
In Angular.js Is it possible to implement a wrapper that will execute whenever a AJAX post request is made and gets a 401 HTTP response?
My web app makes dozens of RESTful requests to the server. If their login session expires the server returns a HTTP 401 response. Now, that doesn't trigger the 'fail' function of the post request (annoyingly). But even if it did, I don't want to now edit dozens of RESTful requests functions and have them check if the error response == 401 then refresh the page (to force the user to re-login).
I just want to implement a POST wrapper that will affect all current and future requests. Is this possible?
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.