Web UI Timeout?

[Br0kenSilos]

Is it just me or has there been some kind of timeout added to the WebUI? Ever since upgrading to 0.94.0, I have noticed that if a WebUI Windows sits open and inactive for a long time, and then I go back to that tab, it looks just fine. That is until I go to interact with it. (Make a new note, do a search, edit the note on the current page, etc.. ) Then it will through some quick errors that pass by on the top of the screen. It does this until I refresh the browser, at which point it takes me all the way back to the login screen. I login again and it seems fine and happy again. Anyone else noticing this behavior since moving to 0.94.0?

[dosubot[bot]]

There was a significant change in session management in 0.94.0: sessions are now stored in the database instead of as files, which improves reliability, especially on Windows. However, the core logic for session expiration and timeouts (like the session duration and protected session timeouts) remains the same and is controlled by configuration settings such as cookieMaxAge (defaulting to 21 days) and, for protected sessions, a separate timeout value. If your session expires after inactivity, the WebUI will show errors until you refresh and log in again—this is expected behavior if the session has expired on the server side, even if the UI still looks active at first glance. There are no open issues or documentation changes specifically about new or shorter timeouts in 0.94.0, so this behavior is likely a result of the improved session backend rather than a new bug or intentional change in timeout duration. You can review or adjust your session timeout settings if needed for your use case.
Release notes reference

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[Br0kenSilos]

Ah ok. That makes sense. The only odd thing in my case is that I haven't had any sessions open for 21 days. In fact 0.94.0 has not even been out that long. This seems like it has been closer to the 24 hours mark (although I have not clocked it). Where would I check/set the cookieMaxAge?

[dosubot[bot]]

You can check or set the cookieMaxAge setting (which controls how long sessions last) in your server configuration. It's defined as a configurable option in apps/server/src/services/meta/config.ts, and the config.ini.template file in the server directory shows all available config options, including session settings. To change it, copy the relevant setting from config.ini.template into your actual config.ini (or set it as an environment variable if your deployment supports that), then adjust the value as needed. After changing this, restart the server for the new setting to take effect.

If your sessions are expiring much sooner than the default (21 days), double-check your config and any environment variables for overrides, and make sure your browser or any proxies aren’t clearing cookies early.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[Br0kenSilos]

Interesting. I pulled my config.ini and it doesn't have the {session] section at all. I will add it in and restart the container and see what happens. Thanks for the info!

[Br0kenSilos]

Im running the docker image for the server. Ill have to dig in and see if I can find and pull those out. It makes me wonder though if what I am really running into is old 0.93.0 cookie sessions that are suddenly expiring in my browser after playing catch up with the new version changes. I say that because I have been running Trilium(Next) for quite a while without these issues.

[Br0kenSilos]

No. I never use the remember me check box. Its a security habit for me generally speaking. Although I can certainly give that a try if you think thats a good idea. Personally I was wondering the same thing. I know for a fact I have not logged in that many times and it seems to be growing.

[eliandoran]

@Br0kenSilos , ah yes, then there's the explanation.

Internally, the "Remember me" checkbox creates a cookie that expires in almost a month.

Regardless of the choice, we also store the sessions.

• Before In-database session store #1955, the sessions had the same time-to-live as the cookie max age (regardless of whether "Remember me" was checked).
• After it, it uses the session cookie's expiration date. But when "Remember me" checkbox is off, there's no expiration date so it falls back to a default of 1h (which was also the default value of the original store).

@pano9000 , since you've also worked on refactoring the session management some time ago, I think you might also have an opinion on it.

In this case, what's your expectation? To me it makes sense that if "Remember me" is not checked, that the session is not kept around for long.

After consulting a bit an LLM, one recommendation is to refresh the expiry date for each user interaction. That way the token is not lost if there is activity. Nevertheless, we would still have to define a time-to-live (but perhaps 1h is still decent).

[Br0kenSilos]

Yep. That makes total sense and aligns with what I am seeing. Obviously, I can't speak for everyone. But for my part, I would like for it to stay logged in as long as I have it in an open tab somewhere. (the previous behavior basically) I often have 2-4 browser Windows open and each might have 2-10 tabs (Yes my mind is a cluttered mess LOL). And in some cases, I have even had two Trilium tabs open, although that is usually by accident. But I generally don't like to use "Remember Me" options because once I close out of something, I like to be forced to log back in. In my higher security things like MS 365 Control/Azure, gmail, etc.. I will go a step further and actually log out instead of just closing the tab Window. This aids in preventing session theft.

[eliandoran]

@Br0kenSilos , yup, it's a pretty fair take.

Nevertheless, if "Remember me" unticked means "session cookies" that don't have an actual expiration date, but live only for the current browser session, storing that session information for 21 days seems a bit much.

In that case I think we'll go with a rolling session cookie. If there's no activity, the session is removed after 24h.

[Br0kenSilos]

Yep. To me that (24h rolling session) seems very reasonable. I suppose one option would be to make that a back end parameter that could be set in the config file or in the docker-compose.yml file perhaps. Although that may be more effort than its worth. I don't know how many other people have/will run into this issue.

[eliandoran]

See https://github.com/TriliumNext/Notes/issues/2196.