Open Bug 1291893 Opened 9 years ago Updated 4 months ago

basic authorization header is not added to service worker fetch() network request

Categories

(Core :: DOM: Service Workers, defect, P5)

defect

Tracking

()

People

(Reporter: bkelly, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: dom-lws-bugdash-triage)

STR: 1) git clone https://github.com/mozilla/serviceworker-cookbook.git 2) cd serviceworker-cookbook/offline-fallback 3) Save the attached python script in the same directory 4) python SimpleAuthServer.py 8080 foo:bar 5) Launch new firefox instance 6) Browse to localhost:8080 7) Enter foo and bar for username and password. 8) Reload a few times. 9) Close firefox and reopen a new instance 10) Navigate to localhost:8080 11) Observe that the page shows an authorization failure. It works the first time because the navigation is not intercepted by the service worker. It goes the network directly and basic auth does its normal thing. We then seem to cache basic authorization credentials for the life of the session. On the next browser load the service worker pass-through fetch() does not prompt for username and password. Instead it just doesn't add an Authorization header. This is likely because we don't know which window initiated the request. We most likely need bug 1183625 to fix this. So we can trace back to our originating window to show the prompt. There is a similar issue with things requiring client certs, etc.
Priority: -- → P2
Thanks, Ben. This indeed is the bug that I intended to report.
Priority: P2 → P3
It seems I never attached the SimpleAuthServer.py script I mentioned in comment 0.

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
Whiteboard: dom-lws-bugdash-triage

I ran into this issue while working on offline support for a personal storage / NAS setup, which uses basic auth for simplicity. When the auth-requiring page is reopened after a browser restart, no auth dialog is shown. Force-reloading (bypassing the serviceworker) can force the authentication dialog & get things unstuck, but that is not very usable for non-technical users.

Chrome / chromium shows a basic auth dialog when re-opening the page after a browser restart, as expected.

As a work-around, I found that firefox will show the auth dialog when the serviceworker does not return a response from the fetch handler. Basically:

if (resp.status === 401) {
        // Firefox does not show the basic HTTP auth dialog when we return a
        // 401 response from the SW, so return undefined and let the browser re-send
        // the request directly.
        // See https://bugzilla.mozilla.org/show_bug.cgi?id=1291893
        return;
}
You need to log in before you can comment on or make changes to this bug.