UX: Reloading pages forces the users to login

[janaka]

Describe the bug
After login if you hit refresh in the browser you have to login.

Clicking on these manage documents links also open in a new window and force the user to login again

To Reproduce
Steps to reproduce the behavior:

1. click on General Chat
2. Login
3. Hit refresh in your browser

Expected behavior
User remains logged in until the session expires or explicit logout action. Refresh any page shout not force a user to login. It should reload the page as expected.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• OS: [e.g. Ubuntu 22.04, macOS 11.4]
• Code Version main branch latest (27 June 2023) commit c4314d2
• Other Runtime Versions (please list below)

Additional context
Add any other context about the problem here.

[janaka]

@osala-eng once PR #36 is merged can you take a look at this one please.

[osala-eng]

@osala-eng once PR #36 is merged can you take a look at this one please.

@cwang @janaka

Currently the auth_state is stored in the st.session_state which is tied to the socket connection that gets reset on page refresh forcing a re-login.

To persist the auth state we could make use of the browsers local storage to store the auth_state.
The library extra-streamlit-components https://pypi.org/project/extra-streamlit-components/ already has a module to interact with the local storage that we could use.

Sould I go ahead with this?

[cwang]

Probably needs a server-side component to make sure it's validated instead of trusting the client-side alone.

Or something like https://pypi.org/project/streamlit-cookies-manager/ where we could encrypt values

[osala-eng]

Probably needs a server-side component to make sure it's validated instead of trusting the client-side alone.

Or something like https://pypi.org/project/streamlit-cookies-manager/ where we could encrypt values

Okay, Let me use this.

[janaka]

this still feels like a bug with with the way we are using this. I've not looked into it so might be wrong.

[janaka]

Seems like their naming and implementation here is a bit poor.

https://discuss.streamlit.io/t/why-session-state-is-not-persisting-between-refresh/32020

Some other options:

[cwang]

st.cache is the only viable option as the other two are deprecated.
This could be the reason to steer us towards FastAPI and then custom-built frontend, depending on whether we want to tackle it now or later.

[janaka]

Doesn't feel bad enough so far to justify a rebuild now (given where we are). But we should start introducing a FastAPI in parallel for other uses cases (like chrome ext) with a view of moving the web UI later.

Note just learnt this is also the cause of login screen when navigating links adding in MD.

[janaka]

@osala-eng using JWT would probably avoid having to read/write user context from the database.

[janaka]

@osala-eng so it looks like the following two are the 3rd party components for cookie management. Forum chat seems to imply that they are secure. Also, the first one looked like it sets the secure and samesite flags. iirc you said doesn't work on HTTPS?

We should be able to mitigate replay attacks pretty easily I think by adding a timestamp or previous token and checking etc. but we can address that in a separate PR.

Feature toggling is the short term mitigation.

• https://github.com/Mohamed-512/Extra-Streamlit-Components/blob/master/extra_streamlit_components/CookieManager/__init__.py

• (the one Chen mentioned above and in the PR) https://github.com/ch-saeki/streamlit-cookies-manager/blob/main/streamlit_cookies_manager/cookie_manager.py

FWIW - I did dig into the streamlit server and runtime code. I was also not able to see a way to set headers server side. The web server instance singleton is simply not exposed, even internally. The server init method doesn't even return and instance of the tornado webserver.