1573489 - localStorage values not surviving through browser redirects during oauth 2 flow under private browsing

Status: RESOLVED WORKSFORME

(Core :: Storage: localStorage & sessionStorage, defect, P3)

Description

[Bruce Roberts]

Attachment: OS and FF version info

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.87 Safari/537.36

Steps to reproduce:

Open FF private window
Enter url to product: https://resolutionrooms.supplychaininsights.ibm.com
Enter information login to underlying auth id system (IBM id).

Actual results:

Error page is shown

Expected results:

product page should be shown.

Comment 1

[Bruce Roberts]

Here's more details I found in my debugging the issue:

1. . Doesn't happen if FF developer tools are open
2. . Error page is shown by our product because 'state' value in localStorage is not maintained through redirects and location switching during oauth flow user authentication screens.
3. . Problem is seen on Windows system as well.
4. Problem is not seen in Chrome.
5. Problem has been worked around by adding a delay to url location switching as follows
   i) window.location.assign(url) ->
   ii) setTimeout(window.location.assign(url), 3000);

I'm filing this bug as requested in comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1536797

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Ah, so, I think the key thing here is private browsing, which makes this bug 1453699 (or the more specific bug 1505461) duped to that. I believe this should be fixed in Firefox nightly if you want to test there.

Assuming this all happens in a single tab with no use of window.open() popups, the most likely explanation is that the page that stores data in localStorage is doing something that prevents the page from being added to the bfcache or the redirect chain is deep enough the page is getting evicted from the bfcache. (For example, if the page has added a "beforeunload" handler to the window.)

ii) setTimeout(window.location.assign(url), 3000);

Is this the literal code in use? The code in this case is still synchronously updating the assignment and is defined to return void, so this is roughly the same code as window.location.assign(url); setTimeout(undefined, 3000);. It seems like this is probably sufficient to alter the lifetime of the window such that the underlying storage doesn't get freed before the navigation completes, but is perhaps not a guarantee.

The most reliable workaround is likely to use document.cookie to store the data in a way that has less chance for data-loss. Other workarounds, as mentioned above, are to help keep a window for the origin that has localStorage that you want to keep around by avoiding bfcache eviction, or through use of window.open(). Under all release builds of firefox, using window.open is sufficient to force the opened tab to be in the same process, but you might encounter issues with popup blocking, etc.

Comment 3

[Bruce Roberts]

Thank you Andrew! I tried the nightly build and the problem does not appear.

When can a customer get a stable firefox release with this change? I see that the nighly is 70.0A1 - does that mean it will appear in version 70.0?

Thanks again.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

The situation is that we have 2 implementations of localStorage in Firefox. Which implementation is used is chosen at startup by "dom.storage.next_gen". It's already possible to flip this preference on the current stable release, 68. We hope to ship 70 with the preference turned on. The reason we haven't shipped with it yet is because the localStorage API is synchronous and we use our QuotaManager storage subsystem to provide the storage.

QuotaManager initialization is asynchronous which traditionally is not a problem because the other APIs we've shipped based on it are also asynchronous (IndexedDB, Cache API, etc.) On machines with slow I/O and large numbers of stored origins, initialization can take multiple seconds. And when web extensions are in use that use localStorage for persistence, and when there are also web extensions that perform interception of all HTTP requests (ex: uBlock, and it need not be the same extension in each case because they all live in the same process), it can take a few seconds at startup before web browsing works because the web extension process is blocked on the synchronous localStorage startup which is blocked on the async QuotaManager startup. We're currently working on caching QuotaManager startup so performance goes from O(n * lots of disk) to O (1 * tiny amount of disk). That should land in 70 and, fingers crossed, work without issue and then we can ship LocalStorage Next Gen (LSNG).

Note that because we have intentionally not turned on LSNG on 68 or 69, if someone were to flip the pref and experience problems, the only solution is to flip the pref off. We likely would not uplift any changes to those releases. (But if any problems can be reproduced on nightly or releases where we have enabled the pref, we would very much appreciate bugs being filed, etc.!)

Hope that provides context.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

(I'm going to leave this bug open for now for duping purposes until we're sure LSNG is riding to beta.)

Comment 6

[Peter Menze]

Hi, I'm not sure how this relates to the linked issues (like 1526949), so I post it here:

Starting with Firefox 70.0.1 and NGLS deactivated there are problems in oauth flows and private browsing.

1. open private mode window in Firefox
2. before directing the user to the auth-endpoint, write a "nonce" value to the localstorage
3. then call the auth-server using window.location.href=.... including the nonce value in the URL
4. when the auth server redirects back, it delivers the original nonce value in the URL (within an ID token)
5. because the nonce value from step 2 is no longer present in the local storage, it's impossible to check if it has changed during authentication

To reproduce I served these 4 files:
https://github.com/pmenze/firefox-localstorage-bug/tree/master/src
in a nginx 1.15.5 server (https, windows 10 64 bit).
Then called https://<server>/one.html on Firefox (70.0.1 64bit Windows 10)

After first "redirect" it shows an alert message, which shows the problem.
In Firefox versions < 70 it works (= no alert message is shown)

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

As per comment 5 we believe LSNG fixed this. We definitely understand how this was happening before, with pre-LSNG maintaining data in the content process and not synchronizing it, but LSNG maintains the data in the parent process so redirects that discard processes are not a problem.