Replies: 1 comment
-
This crate follows the Django semantics and specifically here that means that a session does not set In the Django implementation there's a couple ways around this, such as setting SAVE_EVERY_REQUEST to true. We could provide a similar setting if that's helpful to you. Otherwise this is expected behavior; after all the method is |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Bug Report
Version
0.12.2
Platform
Linux hostname 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux
Description
Calling
session.save()
correctly creates new sessions in the backing store but the cookie is not set.I'm implementing a login handler.
My sessions are stored in a database table (using
tower-sessions-rorm-store
) and my table stores additional data besides theid
,data
andexpiry_date
stored in yourRecord
type.My handler code basically checks the credentials, calls
session.save()
(which creates the session in the DB) and then uses the session's id to set some additional information on my DB column directly, but leaves the session's data hashmap unchanged.I expected to see this happen: A new session is created in the DB and the cookie is set.
Instead, this happened: A new session is created in the DB but the cookie is not set.
I "solved" the problem for my project my setting an unused value:
Beta Was this translation helpful? Give feedback.
All reactions