1494601 - User can navigate to URLs that are replaced by history api replaceState

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect, P3)

Description

[Tim Rogowski]

Attachment: history-repro.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36

Steps to reproduce:

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0

Repro steps:
	0. Launch app and auth server from the attached zip: npm run app, npm run auth.
	1. Go to localhost:3001 (redirects to auth server login page on :4001)
	2. Click the Login button (POSTs to auth server and redirects to :3001 with token; token get's saved in storage and history entry is cleared through replaceState)
	3. Click logout (the token is removed from storage)
	4. Click browser's back button
	5. Click browser's forward button
	6. Click browser's refresh button (user gets logged in though he is on localhost:3001/ )

The presented use case is a simplified representation of how OAuth2 login/logout flow (with self-contained non-rovokable tokens) looks like in an SPA that I'm working on. In Firefox I'm able to force login just by using tab history navigation while on Chrome I'm not able to reproduce this problem.


Actual results:

After logout user is able to get back to the logged in sate just by moving through tab history


Expected results:

User should not be able to "log in" by just using "back", "forward", "refresh" or any combination of these actions.

Comment 1

[Tim Rogowski]

Attachment: repro1.avi

Comment 2

[Andrew Overholt [:overholt]]

Thanks for the reduced test case, Tim!

Jan, can you take a look and see what's up? It looks like we're somehow caching the localStorage key/value and restoring it upon refresh.

Comment 3

[Marion Daly [:mdaly]]

Moving to DWS next, removing NI

Comment 4

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

This now works for me on current nightly using the provided testcase (thank you!!). Presumably this was a result of serious enhancements to both the session history spec and our implementation of session history, primarily driven by the fission effort. It seems very unlikely this was actually a LocalStorage problem, but if it was, it likely would have been addressed by Bug 1599979 enabling LSNG on release.

I'm moving this bug go Core :: DOM: Navigation because that's the bugzilla component for https://searchfox.org/mozilla-central/source/docshell/shistory/SessionHistoryEntry.h.