Sessions over Ring's store port (SPEC §11). The host gives {:store s} — any
ring.middleware.session.store/SessionStore — or {:key k}, which selects
Ring's cookie store with that signing key. Nothing else: the base never
generates a key at startup, because a generated key destroys every session
on every deploy and differs per instance, and it does so without a symptom.
Two things the cookie store cannot do, so the host knows what it is choosing:
a cookie session cannot be revoked from the server, and its sealed payload
carries no timestamp, so the cookie's Max-Age is the only expiry there is.
Sessions over Ring's store port (SPEC §11). The host gives `{:store s}` — any
`ring.middleware.session.store/SessionStore` — or `{:key k}`, which selects
Ring's cookie store with that signing key. Nothing else: the base never
generates a key at startup, because a generated key destroys every session
on every deploy and differs per instance, and it does so without a symptom.
Two things the cookie store cannot do, so the host knows what it is choosing:
a cookie session cannot be revoked from the server, and its sealed payload
carries no timestamp, so the cookie's `Max-Age` is the only expiry there is.Ring itself only defaults :path and :http-only. :secure is on so that
the trap is the opt-out a developer writes for http://localhost, not a
default that works beautifully until production. :secure and
:http-only can be switched off with false; :same-site cannot be
removed. No :max-age by default: the host sets the expiry, knowing that
under the cookie store there is no other.
Ring itself only defaults `:path` and `:http-only`. `:secure` is on so that the trap is the opt-out a developer writes for http://localhost, not a default that works beautifully until production. `:secure` and `:http-only` can be switched off with `false`; `:same-site` cannot be removed. No `:max-age` by default: the host sets the expiry, knowing that under the cookie store there is no other.
(generate-key)A fresh signing key as standard base64 with padding (what :key accepts),
for the operator to run once and keep in the environment. Not for startup
code.
A fresh signing key as standard base64 with padding (what `:key` accepts), for the operator to run once and keep in the environment. Not for startup code.
(options config)Ring wrap-session options built from the base's :session config, every
failure raised here and named.
Ring `wrap-session` options built from the base's `:session` config, every failure raised here and named.
(rotate response new-session)Sets new-session on response and asks Ring to issue a fresh session id
for it — the defence against session fixation, which the host must call
right after authenticating someone (SPEC §11). Setting and marking are one
act on purpose: a mark added first and a session assoc'd later would lose
the mark, silently. Under the cookie store there is no id to rotate and
Ring's recreate is a no-op. With a server-side store Ring deletes the old
session first — with a nil key when the request was anonymous, which is
the ordinary login — so a host's store must accept delete-session with
nil.
The CSRF token does not follow the rotation: the new session holds a token minted
for it in this request, or none (security/rotate-token). A response rendered
through the base — a login page — shows that fresh token; a redirect leaves the new
session without one until the next page. Copying the old session into new-session
is fine, its token is dropped: whoever fixed the old session knew it.
Sets `new-session` on `response` and asks Ring to issue a fresh session id for it — the defence against session fixation, which the host must call right after authenticating someone (SPEC §11). Setting and marking are one act on purpose: a mark added first and a session assoc'd later would lose the mark, silently. Under the cookie store there is no id to rotate and Ring's recreate is a no-op. With a server-side store Ring deletes the old session first — with a nil key when the request was anonymous, which is the ordinary login — so a host's store must accept `delete-session` with nil. The CSRF token does not follow the rotation: the new session holds a token minted for it in this request, or none (`security/rotate-token`). A response rendered through the base — a login page — shows that fresh token; a redirect leaves the new session without one until the next page. Copying the old session into `new-session` is fine, its token is dropped: whoever fixed the old session knew it.
(wrap handler config)ring.middleware.session/wrap-session with the base's options.
`ring.middleware.session/wrap-session` with the base's options.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |