Hi there. I'm not too familiar with OAuth or jQuery. Could you post a working (in Firefox or old Chrome) example that we could use to further diagnose the issue? I'm not unable to use the provided script (missing guid variable, 401 response when I make one up). A simple jsbin/jsfiddle would do. Thanks!

Unable to reproduce this issue on reported version 65.0.3325.181 using Windows 7 with steps mentioned below. Attaching screencast for reference.

1. Launched chrome and opened devtools sources tab. Added given JS file as Snippet and run it. -- Observed error in console.

@Reporter: Could you please check the video and let us know if we miss anything. Also please guide us in how to make a ajax call. Any further information on reproducing the issue will help in further debugging.

Thanks!

Deleted: 825567.mp4 1.2 MB

	825567.mp4 1.2 MB View Download

Here is a minimal but complete example on how to reproduce the problem. This code runs on earlier Chrome versions and Firefox. When ok, an alert box with "Get token ok" is shown, otherwise the alert box shows "Get token failed".

Deleted: index.html 469 bytes

index.html 469 bytes View Download

Deleted: JIT.js 1.6 KB

JIT.js 1.6 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I also encountered this earlier. I believe it was introduced here:
https://chromium.googlesource.com/chromium/src/+/13b9fae4754806a5a72df14b71cc409f73caa8d2/services/network/public/cpp/cors/cors.cc#82

It looks like a misinterpretation of the spec, which notes that null does not mean the string "null"
https://fetch.spec.whatwg.org/#cors-check

Ah, thanks for pointing that out - that'll make triage and fixing much quicker. Over to toyoshim@, who landed 13b9fae4754806a5a72df14b71cc409f73caa8d2, to investigate.

Able to reproduce this issue on reported version 65.0.3325.181, on latest beta 66.0.3359.45 and on latest canary 67.0.3381.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04.

Good Build: 65.0.3324.0
Bad Build: 65.0.3325.0

You are probably looking for a change made after 530115 (known good), but no later than 530116 (first known bad).
CHANGELOG URL:
 https://chromium.googlesource.com/chromium/src/+log/60e9c910417b9685d5a782526d50ea3523421eb3..13b9fae4754806a5a72df14b71cc409f73caa8d2

Reviewed-on: https://chromium-review.googlesource.com/866617

Suspecting same from changelog.

@ toyoshim: Please confirm the bug and help in re-assigning if it is not related to your change. Adding RB-Stable for M-65. Please remove if not the case.

Thanks! 

This is related to the library change we rely on to calculate the request origin.

The file URLs are parsed as ('file', '', 0) by url/origin in the new implementation. This results in serializing the request origin to "file://" rather than "null". (Since actual HTTP Origin header is still calculated in the old code path, "null" is still sent so far).

So in the reported case, the CORS failure does not happen at the CORS check step 2 as suspected at c#8, but happens at the step 4 due to "null" != "file://".

Let me ask Mike to confirm what is desirable origin for file:// URL initiators.
At least, we should use the consistent value, "null" or "file://", for both the Origin header and the CORS origin check.

Transiently assign to Mike to get an answer on "null" or "file://" question.

More implementation details:

<Old>
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp
SecurityOrigin::SerializesAsNull() returns true for local files by default, and SecurityOrigin::ToString() returns "null".
(--allow-file-access-from-files may change this behavior)

<New>
https://cs.chromium.org/chromium/src/url/origin.cc
Origin::Serialize() returns "file://" for local files.

Comments on Origin::Serialize() seems to imply that using file:// is non-standard behavior. So at least for this short term fix, I'd prepare a small fix to serialize file schemes to "null" only for the cors check.

https://chromium-review.googlesource.com/c/chromium/src/+/983276 here is a fix.
Mike, please let me know if you have a right direction how the origin serialization should be.

Discussed in the code review.
Take the ownership back.

M65 has been out since 03/06/18 and we're NOT planning any further M65 respin unless extremely critical issue arise. Please target this for M66 which is going to stable in few weeks. Pls let us know ASAP if there is any concern here. Thank you.

The problem affects only when a user want to connect from a local file to a remote service. Since local file handling is not standardized, I think this is not a critical issue that needs a stable merge.

So, targeting 66 sounds reasonable to me.

I will remove M-65 and Target-65 from the label list. Please revise it if it isn't reasonable.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4

commit d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Thu Mar 29 09:30:27 2018

OOR-CORS: serialize local file initiators to 'null' for CORS check

The code, url::Origin, that new CORS implementation relies on serializes
local file initiators to 'file://' rather than 'null'. This results in
CORS check failures even if the server allows 'null' origin to access.

Bug:  825567 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Icb387b6df6e1e6574ff90cad61f53400092cbcb3
Reviewed-on: https://chromium-review.googlesource.com/983276
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546777}
[modify] https://crrev.com/d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4/services/network/public/cpp/cors/cors.cc
[modify] https://crrev.com/d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4/services/network/public/cpp/cors/cors.h
[modify] https://crrev.com/d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4/services/network/public/cpp/cors/cors_url_loader.cc
[modify] https://crrev.com/d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4/third_party/WebKit/Source/platform/loader/cors/CORS.cpp

merge request for the fix of c#21.

This bug requires manual review: M66 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on chrome reported version 65.0.3325.181
Verified the fix on Mac 10.12.6, Windows-10 & Ubuntu 14.04 on Chrome version #67.0.3384.0 as per the comment#6
Attaching screen cast for reference.
Observed "An alert box with "Get token ok""
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

Deleted: 825567.ogv 690 KB

	825567.ogv 690 KB View Download

Approving merge for M66. Branch:3359

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/52e465a3ea225af65558b682058bd99dbdf86105

commit 52e465a3ea225af65558b682058bd99dbdf86105
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Tue Apr 03 04:59:32 2018

OOR-CORS: serialize local file initiators to 'null' for CORS check

The code, url::Origin, that new CORS implementation relies on serializes
local file initiators to 'file://' rather than 'null'. This results in
CORS check failures even if the server allows 'null' origin to access.

Bug:  825567 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_mojo
Change-Id: Icb387b6df6e1e6574ff90cad61f53400092cbcb3
Reviewed-on: https://chromium-review.googlesource.com/983276
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#546777}(cherry picked from commit d5e1f8bf0103d919895f0b1460b2c3d58a3d29b4)
Reviewed-on: https://chromium-review.googlesource.com/991692
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/branch-heads/3359@{#546}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/52e465a3ea225af65558b682058bd99dbdf86105/services/network/public/cpp/cors/cors.cc
[modify] https://crrev.com/52e465a3ea225af65558b682058bd99dbdf86105/services/network/public/cpp/cors/cors.h
[modify] https://crrev.com/52e465a3ea225af65558b682058bd99dbdf86105/services/network/public/cpp/cors/cors_url_loader.cc
[modify] https://crrev.com/52e465a3ea225af65558b682058bd99dbdf86105/third_party/WebKit/Source/platform/loader/cors/CORS.cpp

The issue was fixed on m67 trunk, and the fix was merged to m66 branch.
I have no plan to merge this to m65 stable branch at this moment.

I will close this issue as Fixed now.

Able to reproduce the issue on chrome reported version 65.0.3325.181
Verified the fix on Mac 10.12.6, Windows-10 & Ubuntu 14.04 on Chrome version #66.0.3359.81 as per the comment#6
Attaching screenshot for reference.
Observed "An alert box with "Get token ok""
Hence, the fix is working as expected.
Adding the verified label.

Thanks!

The NextAction date has arrived: 2018-04-09

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a31f2ec67e9a963dce449519cdb090d16f421c3

commit 1a31f2ec67e9a963dce449519cdb090d16f421c3
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Tue Apr 10 07:44:45 2018

OOR-CORS: browser tests to verify CORS checks for file initiated requests

This patch adds some browser tests that verifies CORS checks for
requests initiated from local files.

Tests verify if;
 - HTTP request has an expected Origin header, 'null' for production mode,
   'file://' for test mode with --allow-file-access-from-files flag.
 - CORS check pass iff the server allow 'null' origin for production
    mode, 'file://' origin for the test mode.

These tests should be provided over file:// protocol, and need to modify
--allow-file-access-from-files flag. That requires exaggerated setup if
we want to have these tests in Blink layout tests, that's why these are
in browser tests here though relevant implementations are in Blink and
the network service.

Bug:  825567 
Change-Id: I986a110f6cddc0349b83cb0ade16ef30581c6ce4
Reviewed-on: https://chromium-review.googlesource.com/987593
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549447}
[add] https://crrev.com/1a31f2ec67e9a963dce449519cdb090d16f421c3/content/browser/loader/cors_file_origin_browsertest.cc
[modify] https://crrev.com/1a31f2ec67e9a963dce449519cdb090d16f421c3/content/public/test/browser_test_base.cc
[modify] https://crrev.com/1a31f2ec67e9a963dce449519cdb090d16f421c3/content/public/test/browser_test_base.h
[modify] https://crrev.com/1a31f2ec67e9a963dce449519cdb090d16f421c3/content/test/BUILD.gn
[add] https://crrev.com/1a31f2ec67e9a963dce449519cdb090d16f421c3/content/test/data/loader/cors_file_origin_test.html

 Issue 831147  has been merged into this issue.