What a browser carries between requests: a small map of strings, signed into one cookie.
A handler reads it off Request.session and hands the one it wants kept to Response.withSession; a response that names none keeps the request's. The write happens once, after dispatch, and only when something changed, so a page that reads the session costs no Set-Cookie. Flash rides inside the same cookie: value) writes a value for the next request and no other, where flash(name) reads it, which is how a create can say "created" on the page it redirects to.
Three maps rather than one, because a value has three lives here: an entry stays until removed, a flash written now is pending until the cookie goes out, and a flash that came in is delivered now and dropped from what goes out. The application sees entries and the two flash doors; the names eezo reserves for itself start with an underscore and cannot be set from outside, the way _method and _csrf are reserved among form fields.
Whether the application holds any entry of its own. Flash does not count, and neither does what eezo keeps under its reserved names: a session that carries only a flash, or only the CSRF token dispatch minted into it, holds nothing the application put there.
Whether the application holds any entry of its own. Flash does not count, and neither does what eezo keeps under its reserved names: a session that carries only a flash, or only the CSRF token dispatch minted into it, holds nothing the application put there.
Deliberately not "nobody is signed in". The signed in user's key is a reserved entry too, so a session naming a user still answers true here. The one caller that matters, Csrf.protect, is asking whether a handler emptied the session on purpose, and it asks about the token in the same breath, so a login response, which carries a freshly minted one, never reaches that arm.
