/whoami page appears logged out after browser history navigation

[victorlin]

Current Behavior

Using Vivaldi (Chromium 132):

bug.mov

Expected behavior

It works fine on Safari:

good.mov

How to reproduce

Steps to reproduce the current behavior:

1. Log into nextstrain.org
2. Go to any page with a user button (including auspice views)
3. Click on the user button to navigate to /whoami
4. Use web browser functionality to go back to the previous page in history
5. Use web browser functionality to go forward in history
6. Observe message "You are not logged in."

[tsibley]

@victorlin Can you record what network requests (if any) are happening on the navigation back?

(I hate that there's a separate network request for logged in status, but there is because of no SSR.)

[genehack]

(I hate that there's a separate network request for logged in status, but there is because of no SSR.)

FWIW, now that the /whoami page is built with the App Router, the component could be converted to a server-side thing, I think.

I'm not doing it as part of the /pathogens port, but I am considering doing something similar with the /list-resources call that's used to build that page.

[victorlin]

Oddly, I can't reproduce this when Dev Tools is opened. It seems like some cache is being bypassed even though "Disable cache" is not enabled.

inspector.mov

[tsibley]

Capture the requests at the actual network level then, i.e. not in browser?

I'm asking about requests because I'm curious if it's a) making a request to /whoami but not sending cookies or something (because of weird/incorrect application of SameSite=Lax?) or b) not making the request at all and doing navigation restoration using a cached copy of the page that was cached too early (i.e. before the original page load was able to swap out "Login" for "victorlin") or c) something else entirely. Basically, trying to narrow down the bug space based on my understanding of potential failure modes.

[tsibley]

It seems like some cache is being bypassed even though "Disable cache" is not enabled.

I wonder if the recent navigation cache is separate from the HTTP cache?

[victorlin]

Capture the requests at the actual network level then, i.e. not in browser?

This is using tcpdump. If I'm interpreting correctly, the first browser history navigation back to /whoami sends a request, but subsequent back-and-forth navigations do not send any requests which point to (b).

tcpdump.mov

[tsibley]

I might be illuminating to see what it's doing on that first history navigation forward to /whoami when it makes at least one request. If you use something like mitmproxy (or can reproduce this locally over HTTP instead of HTTPS) you can see the actual requests.

[tsibley]

FWIW, I installed Vivaldi and couldn't reproduce this.

Vivaldi     7.1.3570.60 (Stable channel) stable (64-bit) 
Revision    97687798ac93cac9ba4ee62b549075f7d6400ec9
OS          Linux
JavaScript  V8 13.2.152.41
User Agent  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36

[victorlin]

Thanks for the pointers. Having trouble getting mitmproxy to intercept traffic straight from the browser. When I use mitmweb, the web version of mitmproxy, it doesn't repro. Might be due to the browser detecting that there is a proxy in place and behaving differently (indicated by the red ⚠️, I had to click to consent).

mitmweb-no-repro.mov

I've reproduced this on two Macs with:

Vivaldi     7.1.3570.60 (Stable channel) (arm64)
Revision    97687798ac93cac9ba4ee62b549075f7d6400ec9
OS          macOS Version 15.3.1 (Build 24D70)
JavaScript  V8 13.2.152.41
User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36

Later I may try getting mitmproxy to work or reproducing locally with HTTP, but this seems to be something that affects few users in few scenarios, so it's not high priority.