Google Contacts API from browser blocked by CORS policy
I am having some trouble making request to the Google Contacts API from my browser in a development environment.
I am trying to request the contacts feed from my web app hosted at https://localhost:3001 by making an XHR request to https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0
We had previously been using JSONP to make this request (as was suggested in various other help forums), but this recently started failing with this error:
Refused to execute script from 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0&callback=jQuery33107099178438653957_1542737952472&_=1542737952473' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
I understand that this is now failing because the browser is checking the mimetype of the response and because it is not application/javascript
, it is not supposed to be evaluated as a script and therefore JSONP does not work. We have tried to ask for application/javascript
but it seems like the API will not give us a response with that mimetype.
Now we are trying to clean up our act, but we are running into a CORS issue which I imagine is the reason the entire Internet has been telling each other to use JSONP in the first place.
When we try to make the request without JSONP, we get this error
Access to XMLHttpRequest at 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0' from origin 'https://localhost:3001' 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.
However, deep in a Google support forum, someone suggested using googleapis.com
instead of google.com
. As a lark, we tried it, and it does indeed work. My problem now is I have no idea why this works or it it will continue to work. The docs do not mention using this new host- they do mention a googleapis.com
URL as a read-only OAuth scope, but that seems tangential to this issue. Is googleapis.com
indeed the new hostname we should be using to get Contacts from a browser?
EDIT: Including the code that makes the request
const params = $.param({
alt: 'json',
access_token: 'MYTOKEN',
'max-results': 5000,
v: '3.0'
})
const url = `https://www.google.com/m8/feeds/contacts/default/thin?${params}` # when I change this to www.googleapis.com it works
$.get(url, responseHandler)
EDIT: Including the request headers on the CORS preflight OPTIONS request that my browser is sending for some reason:
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: x-csrf-token
Access-Control-Request-Method: GET
Cache-Control: no-cache
Connection: keep-alive
Host: www.google.com
Origin: https://localhost:3001
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel …) Gecko/20100101 Firefox/63.0
google-api cors google-contacts gsuite googlecontactsapi
add a comment |
I am having some trouble making request to the Google Contacts API from my browser in a development environment.
I am trying to request the contacts feed from my web app hosted at https://localhost:3001 by making an XHR request to https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0
We had previously been using JSONP to make this request (as was suggested in various other help forums), but this recently started failing with this error:
Refused to execute script from 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0&callback=jQuery33107099178438653957_1542737952472&_=1542737952473' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
I understand that this is now failing because the browser is checking the mimetype of the response and because it is not application/javascript
, it is not supposed to be evaluated as a script and therefore JSONP does not work. We have tried to ask for application/javascript
but it seems like the API will not give us a response with that mimetype.
Now we are trying to clean up our act, but we are running into a CORS issue which I imagine is the reason the entire Internet has been telling each other to use JSONP in the first place.
When we try to make the request without JSONP, we get this error
Access to XMLHttpRequest at 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0' from origin 'https://localhost:3001' 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.
However, deep in a Google support forum, someone suggested using googleapis.com
instead of google.com
. As a lark, we tried it, and it does indeed work. My problem now is I have no idea why this works or it it will continue to work. The docs do not mention using this new host- they do mention a googleapis.com
URL as a read-only OAuth scope, but that seems tangential to this issue. Is googleapis.com
indeed the new hostname we should be using to get Contacts from a browser?
EDIT: Including the code that makes the request
const params = $.param({
alt: 'json',
access_token: 'MYTOKEN',
'max-results': 5000,
v: '3.0'
})
const url = `https://www.google.com/m8/feeds/contacts/default/thin?${params}` # when I change this to www.googleapis.com it works
$.get(url, responseHandler)
EDIT: Including the request headers on the CORS preflight OPTIONS request that my browser is sending for some reason:
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: x-csrf-token
Access-Control-Request-Method: GET
Cache-Control: no-cache
Connection: keep-alive
Host: www.google.com
Origin: https://localhost:3001
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel …) Gecko/20100101 Firefox/63.0
google-api cors google-contacts gsuite googlecontactsapi
1
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails forwww.google.com
succeeds forwww.googleapis.com
.
– sans
Nov 20 at 21:59
1
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02
add a comment |
I am having some trouble making request to the Google Contacts API from my browser in a development environment.
I am trying to request the contacts feed from my web app hosted at https://localhost:3001 by making an XHR request to https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0
We had previously been using JSONP to make this request (as was suggested in various other help forums), but this recently started failing with this error:
Refused to execute script from 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0&callback=jQuery33107099178438653957_1542737952472&_=1542737952473' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
I understand that this is now failing because the browser is checking the mimetype of the response and because it is not application/javascript
, it is not supposed to be evaluated as a script and therefore JSONP does not work. We have tried to ask for application/javascript
but it seems like the API will not give us a response with that mimetype.
Now we are trying to clean up our act, but we are running into a CORS issue which I imagine is the reason the entire Internet has been telling each other to use JSONP in the first place.
When we try to make the request without JSONP, we get this error
Access to XMLHttpRequest at 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0' from origin 'https://localhost:3001' 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.
However, deep in a Google support forum, someone suggested using googleapis.com
instead of google.com
. As a lark, we tried it, and it does indeed work. My problem now is I have no idea why this works or it it will continue to work. The docs do not mention using this new host- they do mention a googleapis.com
URL as a read-only OAuth scope, but that seems tangential to this issue. Is googleapis.com
indeed the new hostname we should be using to get Contacts from a browser?
EDIT: Including the code that makes the request
const params = $.param({
alt: 'json',
access_token: 'MYTOKEN',
'max-results': 5000,
v: '3.0'
})
const url = `https://www.google.com/m8/feeds/contacts/default/thin?${params}` # when I change this to www.googleapis.com it works
$.get(url, responseHandler)
EDIT: Including the request headers on the CORS preflight OPTIONS request that my browser is sending for some reason:
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: x-csrf-token
Access-Control-Request-Method: GET
Cache-Control: no-cache
Connection: keep-alive
Host: www.google.com
Origin: https://localhost:3001
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel …) Gecko/20100101 Firefox/63.0
google-api cors google-contacts gsuite googlecontactsapi
I am having some trouble making request to the Google Contacts API from my browser in a development environment.
I am trying to request the contacts feed from my web app hosted at https://localhost:3001 by making an XHR request to https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0
We had previously been using JSONP to make this request (as was suggested in various other help forums), but this recently started failing with this error:
Refused to execute script from 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0&callback=jQuery33107099178438653957_1542737952472&_=1542737952473' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.
I understand that this is now failing because the browser is checking the mimetype of the response and because it is not application/javascript
, it is not supposed to be evaluated as a script and therefore JSONP does not work. We have tried to ask for application/javascript
but it seems like the API will not give us a response with that mimetype.
Now we are trying to clean up our act, but we are running into a CORS issue which I imagine is the reason the entire Internet has been telling each other to use JSONP in the first place.
When we try to make the request without JSONP, we get this error
Access to XMLHttpRequest at 'https://www.google.com/m8/feeds/contacts/default/thin?alt=json&access_token=MYTOKEN&max-results=5000&v=3.0' from origin 'https://localhost:3001' 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.
However, deep in a Google support forum, someone suggested using googleapis.com
instead of google.com
. As a lark, we tried it, and it does indeed work. My problem now is I have no idea why this works or it it will continue to work. The docs do not mention using this new host- they do mention a googleapis.com
URL as a read-only OAuth scope, but that seems tangential to this issue. Is googleapis.com
indeed the new hostname we should be using to get Contacts from a browser?
EDIT: Including the code that makes the request
const params = $.param({
alt: 'json',
access_token: 'MYTOKEN',
'max-results': 5000,
v: '3.0'
})
const url = `https://www.google.com/m8/feeds/contacts/default/thin?${params}` # when I change this to www.googleapis.com it works
$.get(url, responseHandler)
EDIT: Including the request headers on the CORS preflight OPTIONS request that my browser is sending for some reason:
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: x-csrf-token
Access-Control-Request-Method: GET
Cache-Control: no-cache
Connection: keep-alive
Host: www.google.com
Origin: https://localhost:3001
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel …) Gecko/20100101 Firefox/63.0
google-api cors google-contacts gsuite googlecontactsapi
google-api cors google-contacts gsuite googlecontactsapi
edited Nov 21 at 22:50
asked Nov 20 at 18:37
sans
99131419
99131419
1
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails forwww.google.com
succeeds forwww.googleapis.com
.
– sans
Nov 20 at 21:59
1
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02
add a comment |
1
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails forwww.google.com
succeeds forwww.googleapis.com
.
– sans
Nov 20 at 21:59
1
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02
1
1
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails for
www.google.com
succeeds for www.googleapis.com
.– sans
Nov 20 at 21:59
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails for
www.google.com
succeeds for www.googleapis.com
.– sans
Nov 20 at 21:59
1
1
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02
add a comment |
1 Answer
1
active
oldest
votes
Thanks to comments from @sideshowbarker, we figured out that we had a jQuery ajaxPrefilter configured to add a x-csrf-token
header to any cross-domain ajax request. This was causing the browser to send the CORS preflight OPTIONS request which was failing.
In our case, the source of the x-csrf-token header was a dependency called ember-cli-rails-addon that adds x-csrf-token to all requests. There is a PR for that project here that fixes that issue.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399417%2fgoogle-contacts-api-from-browser-blocked-by-cors-policy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks to comments from @sideshowbarker, we figured out that we had a jQuery ajaxPrefilter configured to add a x-csrf-token
header to any cross-domain ajax request. This was causing the browser to send the CORS preflight OPTIONS request which was failing.
In our case, the source of the x-csrf-token header was a dependency called ember-cli-rails-addon that adds x-csrf-token to all requests. There is a PR for that project here that fixes that issue.
add a comment |
Thanks to comments from @sideshowbarker, we figured out that we had a jQuery ajaxPrefilter configured to add a x-csrf-token
header to any cross-domain ajax request. This was causing the browser to send the CORS preflight OPTIONS request which was failing.
In our case, the source of the x-csrf-token header was a dependency called ember-cli-rails-addon that adds x-csrf-token to all requests. There is a PR for that project here that fixes that issue.
add a comment |
Thanks to comments from @sideshowbarker, we figured out that we had a jQuery ajaxPrefilter configured to add a x-csrf-token
header to any cross-domain ajax request. This was causing the browser to send the CORS preflight OPTIONS request which was failing.
In our case, the source of the x-csrf-token header was a dependency called ember-cli-rails-addon that adds x-csrf-token to all requests. There is a PR for that project here that fixes that issue.
Thanks to comments from @sideshowbarker, we figured out that we had a jQuery ajaxPrefilter configured to add a x-csrf-token
header to any cross-domain ajax request. This was causing the browser to send the CORS preflight OPTIONS request which was failing.
In our case, the source of the x-csrf-token header was a dependency called ember-cli-rails-addon that adds x-csrf-token to all requests. There is a PR for that project here that fixes that issue.
answered Nov 21 at 20:16
sans
99131419
99131419
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53399417%2fgoogle-contacts-api-from-browser-blocked-by-cors-policy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Please edit the question and add your frontend request code. The error message indicates the request is failing during the CORS preflight OPTIONS request — but your request code should just be making a simple GET request that doesn’t trigger any preflight. So it seems like your request code must instead be adding some unnecessary custom headers to the request. So you should remove any part of your frontend code that adds custom headers to the request.
– sideshowbarker
Nov 20 at 21:36
@sideshowbarker That's a good point. I've added a code snippet to the question. It is just a jQuery.get though, so maybe I'm about to learn something new about how that method works. Also interesting to note that the same code snippet that fails for
www.google.com
succeeds forwww.googleapis.com
.– sans
Nov 20 at 21:59
1
You probably want to examine the OPTIONS request in the Network pane of browser devtools, and check the value of the Access-Control-Request-Headers request header that the browser is sending. That’ll show what headers are being added to the request. I realize now it’s likely the X-Requested-With header. So I you’d need to figure out how to make jQuery add that header, or else use some other request mechanism — e.g., use the fetch API directly — that doesn’t add the X-Requested-With header or other custom headers.
– sideshowbarker
Nov 20 at 22:11
@sideshowbarker It looks like you were only half right ;). Our codebase has a jQuery ajaxPrefilter configured that puts an x-csrf-token header on any cross-site request. That must be triggering the CORS pre-flight. I'll fiddle with it to confirm and answer my own question if it works out. Thanks a ton!
– sans
Nov 21 at 6:02