SESSION_SECRETS accepts a comma-separated list of keys for zero-downtime secret rotation. The first key signs new cookies; the remaining keys were used by trillium-sessions' with_old_secrets() to verify cookies signed by prior keys. But we're moving to Axum, and tower-sessions.
tower-sessions 0.15's SignedCookie accepts only a single signing key. As of #2251, the older keys are still parsed from config -- but we don't actally use them. So rotating the session secret will invalidate all existing sessions (users get logged out).
We can either:
I'm adding a tracing::warn! at startup in #2251 when older is non-empty. This isn't data loss, it's probably totally immaterial, but I want us to talk about it.
I need to file an issue for this, since this is a functionality loss in tower-sessions vs Trillium, and we need to decide what to do.
Originally posted by @jcjones in #2251
SESSION_SECRETSaccepts a comma-separated list of keys for zero-downtime secret rotation. The first key signs new cookies; the remaining keys were used bytrillium-sessions'with_old_secrets()to verify cookies signed by prior keys. But we're moving to Axum, andtower-sessions.tower-sessions0.15'sSignedCookieaccepts only a single signing key. As of #2251, the older keys are still parsed from config -- but we don't actally use them. So rotating the session secret will invalidate all existing sessions (users get logged out).We can either:
SignedCookiewith a custom cookie jar that tries multiple keys on verification,SignedCookie, orI'm adding a
tracing::warn!at startup in #2251 whenolderis non-empty. This isn't data loss, it's probably totally immaterial, but I want us to talk about it.Originally posted by @jcjones in #2251