each time i try to save and train on Luis.ai I just get an error dialog and
Access to XMLHttpRequest at 'https://puzzleqna.cognitiveservices.azure.com/qnamaker/v4.0/knowledgebases/.....
from origin 'https://www.qnamaker.ai'
has been blocked by CORS policy:
Method PATCH is not allowed by Access-Control-Allow-Methods in preflight response.
6.fe97106b3db0546c50…olyfills.chunk.js:2
PATCH https://puzzleqna.cognitiveservices.azure.com/qnamaker/v4.0/knowledgebases/xxx... net::ERR_FAILED
have had this problem over a couple of days so I imagine it's something related to my account but not sure.
Related
I am developing a Laravel API + Vue.js frontend app. Those 2 projects are on separate servers. I am having a CORS policy problem in production (on local I had, but I managed to fix it).
So basically, there are 2 errors right now. I am having this error:
Access to XMLHttpRequest at '--Laravel url--' from origin '--Vue url--' has been blocked by CORS policy: Request header field content-type is not allowed by Access-Control-Allow-Headers in preflight response.
While my co-worker is getting this error:
Access to XMLHttpRequest at '--Laravel url--' from origin '--Vue url--' 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.
We tried a few things:
Configurating CORS on Laravel side:
setting CORS middleware - no effect
changing CORS config .php file - no effect
Configurating CORS on Vue side:
adding origin header to form - no effect
The response is also displaying in browser as being same-site although it is not.
Anyone can help? We have been searching for answer for nearly 3 days.
As Jazerix answered in a comment, going Sanctum is probably the right way because it has most stuff prepared.
I'm new to CORS configuration and trying to figure this out, but my set up looks like it is right according to the documentation. I'm hoping you can help me see what I've missed. My code is trying to upload (PUT) a file directly to google storage using a signed url.
Access to XMLHttpRequest at
'https://storage.googleapis.com/herdboss-dev.appspot.com/uploads/152/152-owner-152-61.jpg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Go...'
from origin 'https://herdboss-dev.appspot.com' has been blocked by
CORS policy: No 'Access-Control-Allow-Origin' header is present on the
requested resource.
I've set the CORS policy on my Google Storage Bucket (added line breaks for readability):
% gsutil cors get gs://herdboss-dev.appspot.com
[{
"maxAgeSeconds": 3600,
"method": ["GET", "HEAD", "PUT"],
"origin": ["https://herdboss-dev.appspot.com"],
"responseHeader": ["X-Requested-With", "Access-Control-Allow-Origin", "Content-Type"]
}]
According to my chrome inspector, the pre-flight request happens and returns the proper methods and headers (as far as I can tell). Also, as a side note, I noticed the PUT shows up in my Chrome inspector before the OPTIONS, but the timestamps show the OPTIONS is sent first.
When the OPTIONS call happens, Google Storage correctly responds and says it can support my request methods GET, HEAD, PUT and origin https://herdboss-dev.appspot.com:
THE PUT REQUEST
However, when the PUT happens, Google Storage does not respond with the proper Access-Control-Allow-Origin header:
What am I missing or doing wrong? I'm able to use these signed urls to PUT files directly into my Google Storage bucket when I make a direct http call, so I know the signed urls work. I'm just running into this CORS problem. It's a new thing for me, I haven't dealt with it before, but it seems like I'm setting all of the things I should be setting.
**EDIT 1:
I tried setting my allowed origins to * just as a test and I was still rejected with the same No 'Access-Control-Allow-Origin' header is present on the requested resource. The Chrome inspector showed the OPTIONS response did send back my * for allowed origins, but it still didn't work and still gave the same error.
Figured it out.
Short version: Chrome's error message about CORS was a red herring. Google Storage was rejecting the request which was being interpreted as a CORS violation.
Long version:
I noticed in Chrome's inspector that the response to my PUT request had a content length of 862 characters, but Chrome wasn't showing me any response. I opened Firefox and tried the upload process again and it failed with the same error messages about CORS and Access-Control-Allow-Origin. However, in Firefox's network inspector, I was able to see the raw response body!
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your Google secret key and signing method.</Message>
<StringToSign>.....</StringToSign>
<CanonicalRequest>PUT
/herdboss-dev.appspot.com/uploads/152/152-owner-152-72.png
X-Goog-Algorithm=GOOG4-RSA-SHA256&....;X-Goog-SignedHeaders=content-type%3Bhost
content-type:image/png
host:storage.googleapis.com
content-type;host
UNSIGNED-PAYLOAD
</CanonicalRequest>
</Error>
My theory is that when Chrome and Firefox do the pre-flight CORS checking and then issue the PUT request and receive a 403 response code that it is responding as if it is a CORS problem even though the problem was not CORS related and the preflight response DID actually have the Access-Control-Allow-Origin header.
From here, I was able to quickly diagnose the problem by checking my url signing code against the request. I noticed that when created the signed upload url that I was requiring a Content-type of application/octet-stream but when the javascript in the browser was doing the PUT request that it was setting the Content-type to image/png. I updated my javascript to force the Content-type to match application/octet-stream and then the request succeeded.
I am having a web-app (serverless) that I am using for a long time. The idea is that the app gets contacts from my Google Account, and then I can do some actions by using this data.
Unfortunately, last days I started to recieve CORS errors... I didn't pay attention, but today I tried to fix it. And I realized that all other Google APIs like maps, locations, OAuth work properly.
The only problematic one is the Google Contacts API. I wonder, it's possible to continue using this API on the client side? I didn't touch the code and google-cloud settings. This is a very strange behavior...
Failed to load https://www.google.com/m8/feeds/contacts/default/full?v=3.0&alt=json&access_token=......&updated-min=2018-08-09T22%3A00%3A21.000Z&max-results=500:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://.....' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
The issue is fixed on Google's side (was a bug).
I have receive the following response when trying to access an API via an ajax request in Chrome:
"Failed to load http://localhost:1880/api_resource: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin http://localhost:3000 is therefore not allowed access."
As you can see from the message, both client and API are running locally.
I understand that this situation relates to a CORS cross origin request. I see that there are similar questions about this on stack overflow, but from those answers I do not understand what the message is telling me and where it comes from.
Specifically I understand that the response header "Access-Control-Allow-Origin" must be set (typically to '*') to allow access to the API from a different domain to the one on which the API is being served. But the message seems to relate to the request and not the response, and as far as I am aware, no request ever reaches the API.
What is a preflight request and how is it failing?
As I now understand it, modern browsers will issue a 'preflight' request before the actual cross origin request. This preflight request uses the 'OPTIONS' HTTP verb along with the CORS headers Access-Control-Request-Method and Access-Control-Request-Headers to which it expects to see a response with valid Access-Control-Allow-Origin in the header that indicates that the server understands the CORS protocol and will allow the actual (GET/POST/PUT) request.
The message "Response to preflight request doesn't pass access control check" means that the browser did not see a valid "Access-Control-Allow-Origin" header in the Options response.
In my case this was because the server (implementing a REST API) was set up to respond correctly to PUT and POST requests but not setup to respond to OPTIONS requests with the CORS headers.
in my case the problem was for my website address, i'm calling all apis from the same server but i got this error.
my website address is sateh.ir
so im my ajax request i set the url: http://sateh.ir/api/...
after getting this error and working on it for some hours, i got that i had to set ajax url to: http://www.sateh.ir/api/...
i dont know why my website cant understand that i'm calling api from the same server if i dont put 'www', but that was my problem at all.
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/