sessiondata

package
v1.2.6 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Oct 17, 2026 License: MPL-2.0 Imports: 5 Imported by: 0

Documentation

Overview

Package sessiondata holds the session keys and the small pieces of session plumbing shared across packages: the admin area and the public handler (which needs to recognize logged-in editors for in-place editing), and the two session stores.

Index

Constants

View Source
const (
	KeyUserID = "cmsUserID"
	KeyCSRF   = "cmsCSRFToken"
	KeyFlash  = "cmsFlash"
	// KeyEpoch is the SessionEpoch of the account KeyUserID names, as it
	// was when the session was granted. See EpochCurrent.
	KeyEpoch = "cmsSessionEpoch"
)

Variables

This section is empty.

Functions

func EnsureCSRF

func EnsureCSRF(ctx context.Context, sessions *scs.SessionManager) (string, error)

EnsureCSRF returns the session's CSRF token, generating and storing one if the session doesn't have one yet.

func EpochCurrent added in v1.2.5

func EpochCurrent(ctx context.Context, sessions *scs.SessionManager, epoch int64) bool

EpochCurrent reports whether the session was granted under the account's current SessionEpoch. Every check that turns a session into a signed-in user asks it, so a password change or a two-factor change ends all of the account's other sessions at their next request. A session from before epochs existed holds none, which reads as 0 — the epoch every account starts at.

func WriteContext added in v1.2.2

func WriteContext(ctx context.Context) (context.Context, context.CancelFunc)

WriteContext is the context a session store should write under, given the one the request arrived with.

Reads take the request's context unchanged: a visitor who has gone away does not need their session looked up, and letting those queries pile up behind a slow store is exactly what a cancellable read prevents.

Writes are different, and this is the whole reason the helper exists. A session write happens because something has already been decided — a login granted, a session destroyed on logout, a token renewed against fixation — and a client that hangs up in the moment between the decision and the write should not undo it. A logout that did not delete the session because the browser went away leaves a session that still works, which is the wrong way for that to fail.

So the cancellation is dropped and a deadline put in its place: the write survives the disconnect, and still cannot run forever. The caller must call the returned cancel.

Types

This section is empty.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL