New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 766139 link

Starred by 7 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac , Fuchsia
Pri: 2
Type: Bug

Blocked on:
issue 771486



Sign in to add a comment

Authorization header for loading type=module scripts is not set

Reported by m...@rkusa.st, Sep 18 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.18 Safari/537.36

Steps to reproduce the problem:
With demo test case:

1. Install demo dependencies with `npm install`
2. Start example Node application with `node server.js`
3. Open `http://localhost:3000/ 
4. Insert any username or password (example accepts all inputs)

Without demo test case:

1. Find and open page that is protected with basic authentication and includes scripts with `<script type="module">`.

What is the expected behavior?
The script loaded with `<script type="module">` should be loaded and executed.
For the testcase: An alert window printing "Works!" should open.

What went wrong?
The request that loads the script referenced in `<script type="module">` does not have the `Authorization` header set. The request will consequentially fail with a `401 Unauthorized`.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 62.0.3202.18  Channel: beta
OS Version: OS X 10.13.0
Flash Version:
 
issue.zip
403 KB Download
Labels: Needs-Triage-M62
Labels: Triaged-ET Needs-Feedback
@ m@rkusa.st:  Unable to reproduce the issue on reported version 62.0.3202.18 by following below steps

1. Install demo dependencies with `npm install`
2. Start example Node application with `node server.js`
3. Open `http://localhost:3000/ 
4. Insert any username or password
It leads to blank page

Could you let us know if we are missing any steps from our end?


Comment 3 by m...@rkusa.st, Sep 22 2017

Thanks for testing! Steps are correct. I've retried the uploaded example (on both Mac and Win) and got the issue on both. I've attached a screenshot to show what I am getting. Is the example showing an Alert window for you?
Screen Shot 2017-09-22 at 15.11.02.png
290 KB View Download
Project Member

Comment 4 by sheriffbot@chromium.org, Sep 22 2017

Cc: divya.pa...@techmahindra.com
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "divya.padigela@techmahindra.com" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: shrike@chromium.org
Labels: Hotlist-HighSierra
Cc: adamk@chromium.org

Comment 7 by adamk@chromium.org, Oct 3 2017

Cc: hirosh...@chromium.org
Components: -Blink>JavaScript Blink>HTML>Script
Labels: -Hotlist-HighSierra OS-Android OS-Chrome OS-Fuchsia OS-Linux OS-Windows
Owner: kouhei@chromium.org
Status: Assigned (was: Unconfirmed)
kouhei, can you direct this appropriately? Not sure if this is something in Blink loading or further down the net stack.
This *was* a spec compliant behavior that all module scripts should be fetched w/ credentials mode "omit".
However, a spec change landed today that we should respect crossorigin attribute for module script too.
[1] https://github.com/whatwg/html/commit/9275d955dcd604e959cfcc672e0c234b1b8c00db

I'll update the impl to match the spec.
Labels: -Needs-Triage-M62 M-63
aiming for m63.
Blockedon: 771486

Sign in to add a comment