[RFE?] Use monotonic clock for expiry checks for in-memory stores

[martinetd]

This is a bit of a specific use-case so probably not fit for RFE.
Let's start with some background: we're using this at $job on embedded systems -- you can think of it as the web server that's almost always present in ISP router boxes, except it's not routers.

One of the issues that crept in recently is that if there's no external connection set up, NTP likely won't be working. At this point, thanks to the cookie only setting max-age and not an absolute expires timestamp, users can log in and do what they need (this was a problem with the old axum-sessions that was using expires with a date in the past... chrome apparently ignores deadlines in 1970 but firefox would just forget the cookie immediately and the login page never worked...)
Now comes the crux of this discussion: if the user's manipulation configure the network (say they add LTE creds or something), then NTP will start working, and time will jump from 1970 to $now.
At that point, all sessions will expire and user will need to log in again for no apparent reason.

It'd be great if sessions could use not OffsetDateTime::now_utc, but instead something like std::time::Instant and relative time comparisons.

This is far from obvious because this obviously cannot work with DB stores -- monotonic time makes no sense in face of application restart or system reboot. Using a monotonic time internally would mean converting it to real time every time at store boundaries, which probably isn't something you'd want.

At this point I think it'd be easier to just go and make my own variant of MemoryStore that ignores session.expiry_date() and stores a fixed Instant + Duration offset instead, as it looks like it should be easy to do -- as far as I can see nothing forbids that and a quick test worked.

What do you think?

[maxcountryman]

Interesting use case.

Taking a step back, it probably is not clear enough that we fully intend users to write their own stores and the ones included here are largely just for convenience.

So I do think a custom store could be appropriate here.

It's worth pointing out that internally OffsetDateTime is used throughout. This could lead to surprising behavior. For instance, max age will still be calculated with UTC now.

[martinetd]

Thanks for clarifying making your own store is supported/encouraged -- in hindsight most big websites will already have a database backend so it totally makes sense, but since we don't the examples looked full enough. I'll go this way.

It's worth pointing out that internally OffsetDateTime is used throughout. This could lead to surprising behavior. For instance, max age will still be calculated with UTC now.

Hmm, as long as it's only used immediately e.g. to set max-age when issuing the cookie then I don't think that'll be a problem, I'll add a check to make sure this behaviour doesn't change.
I've had a quick look and aside of backends OffsetDateTime is only used for modified_at, which if my store backend ignores expiry_date() altogether is probably safe to ignore?
At the very least the session itself doesn't seem to have its own expiry mechanism -- it's fully reliant on the store -- but I couldn't find If that comes up as a problem marking the session expiry as OnSessionEnd end managing it 100% internally might be better..
It took me way too long to figure out what actually sets the "Set-cookie" header (is_modified -> tower-cookies -> similar changed logic -> set in CookieJar -> implemented from cookie-rs...) but ultimately the max-age comes straight from SessionConfig's build_cookie, so what I said above looks ok. As long as the system time doesn't jump exactly when setting the cookie then this is probably fine. At the very least, this specific window is also already a problem and making my own store with Instant will fix the overwhelming majority of use cases, if our user really falls on this problem they'll just have to log in twice in a row...

totally unrelated:

    pub fn is_modified(&self) -> bool {
        let inner = self.inner.lock();
        inner.modified_at.is_some() && !inner.data.is_empty()
    }

Why check data isn't empty? If taking my previous example that just sets login to the session I decide to remove the login field, then is_modified will be false and the session won't be saved so login will persist? (we use .flush() for this so it didn't come up as a problem, but it looks weird to me)

[maxcountryman]

Why check data isn't empty? If taking my previous example that just sets login to the session I decide to remove the login field, then is_modified will be false and the session won't be saved so login will persist?

The code here is more convoluted than I would like. There's a couple of important observations that are likely not as obvious as they should be:

1. Django treats empty sessions as equivalent to deleted sessions; we maintain this semantic,
2. Because we check deletion before saving a session, this check will delete the session before it even reaches the check for modification.

This could no doubt be documented better and the code could perhaps be simplified altho it is a little more nuanced than it might first appear.