1705134 - HTTP credentials in sidebar not shared with other tabs for the same site

Status: UNCONFIRMED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Danny Lin]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

1. Send an AJAX request to a site that requires HTTP basic authorization, say https://example.com/app, in the sidebar.
2. Fill the username and password in the prompt for HTTP auth.
3. Open https://example.com/app in a normal tab in the same window as the sidebar.

Actual results:

Prompt for HTTP auth is shown again for https://example.com/app in the normal tab.

Expected results:

Prompt for HTTP auth should not shown again in the normal tab.

Comment 1

[Andrei Purice]

Setting a component for this issue in order to get the dev team involved.
If you feel it's an incorrect one please feel free to change it to a more appropriate one.

Comment 2

[Valentin Gosu [:valentin] (he/him)]

By sidebar do you mean by opening the page in the sidebar using an extension like this: https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/ ?
Could you check if this bug goes away if you set the privacy.partition.network_state pref to false in about:config ? Thanks!

Comment 3

[Danny Lin]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

By sidebar do you mean by opening the page in the sidebar using an extension like this: https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/ ?
Could you check if this bug goes away if you set the privacy.partition.network_state pref to false in about:config ? Thanks!

Yes, it's resolved after this configuration. Seems to be a side effect of cache partition. But I wonder whether an extension, which already gained host permission, should be a subject of cache partition. Maybe adding a config option to exclude extensions?

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Requests coming from extensions have a different originAttributes from those in regular tabs.
If we are to fix this, we probably need changes somewhere in Necko, but first we should decide what the behaviour we want is. Tim, feel free to bounce back once we reach a decision.

Comment 5

[Tim Huang[:timhuang]]

I think we should treat network requests from extensions as first-party requests. Meaning that the partition key should be the the domain where the extension API requests, like what we did in Bug 1691907 for the downloads API.

Comment 6

[Paul Zühlcke [:pbz]]

I can not reproduce this issue with the given extension: https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/
My STR:

1. Install https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/
2. Click the extension icon on the top right enter https://jigsaw.w3.org/HTTP/Basic/ and click plus. The test page loads in the sidebar, an auth prompt appears.
3. enter guest/guest for user/password. the test page shows "Your browser made it"
4. Open https://jigsaw.w3.org/HTTP/Basic/ in the main tab via the URL bar. The test page shows "Your browser made it". No second prompt is shown.

Tested on Ubuntu 21.04, Nightly 93.0a1 (2021-08-11) .

Danny, can you still reproduce the issue? Perhaps my STR is incorrect? Does it require an actual AJAX request from the extension, e.g. via Fetch?

Comment 7

[Danny Lin]

(In reply to Paul Zühlcke [:pbz] from comment #6)

I can not reproduce this issue with the given extension: https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/
My STR:

1. Install https://addons.mozilla.org/en-US/firefox/addon/webpage-sidebar/
2. Click the extension icon on the top right enter https://jigsaw.w3.org/HTTP/Basic/ and click plus. The test page loads in the sidebar, an auth prompt appears.
3. enter guest/guest for user/password. the test page shows "Your browser made it"
4. Open https://jigsaw.w3.org/HTTP/Basic/ in the main tab via the URL bar. The test page shows "Your browser made it". No second prompt is shown.

Tested on Ubuntu 21.04, Nightly 93.0a1 (2021-08-11) .

Danny, can you still reproduce the issue? Perhaps my STR is incorrect? Does it require an actual AJAX request from the extension, e.g. via Fetch?

It seems that this site has implemented an additional mechanism to persist authorization status. I don't know what exactly the mechanism is, though.

To prove it:

1. Open https://jigsaw.w3.org/HTTP/Basic/ in a tab.
2. Enter guest/guest for user/password. The test page shows "Your browser made it".
3. Restart the browser.
4. Open https://jigsaw.w3.org/HTTP/Basic/ in a tab. The page still shows "Your browser made it".

This doesn't happen on a normal pure-HTTP-auth website, the login information will be cleared at browser restart and auth will be prompted at step 4.

Comment 8

[Danny Lin]

(In reply to Danny Lin from comment #7)

(In reply to Paul Zühlcke [:pbz] from comment #6)

I guess that https://jigsaw.w3.org/HTTP/Basic/ always responses 304 if the request header includes a valid If-Modified-Since and/or If-None-Match header, regardless of whether HTTP auth info is provided. Clear the browser cache makes it require HTTP auth again.