Refactor sessions to frequently rotate

In order to minimise the window of opportunity to steal a session,
automatically rotate it onto a new session on a frequent basis.  This
makes a session cookie older than the automatic rollover time less
likely to grant access and more likely to be detected.

Should a stolen session cookie get rotated while the attacker is using
it, the user will be notificed that their session has been taken the
next time they open the app if the user re-visits the website before the
session is discarded.

docs/admin/config.md

@@ -0,0 +1,17 @@
+<!--
+	SPDX-FileCopyrightText: © 2025 Hornwitser <code@hornwitser.no>
+	SPDX-License-Identifier: AGPL-3.0-or-later
+-->
+# Configuration
+
+## Environment Variables
+
+### NUXT_SESSION_EXPIRES_TIMEOUT
+
+Time in seconds before a session is considered expired and need to be rotated over into a new session. When an endpoint using a session is hit after the session expires but before the session is discarded a new session is created as the successor with a new expiry and discard timeout. The old session then considered to have been superceeded and any requests using the old session will result in a 403 Forbidden with the message the session has been taken.
+
+### NUXT_SESSION_DISCARD_TIMEOUT
+
+Time in seconds before a session is deleted from the client and server, resulting in the user having to authenticate again if the session wasn't rotated over into a new session before this timeout.
+
+This should be several times greater that `NUXT_SESSION_EXPIRES_TIMEOUT`.

docs/dev/sessions.md

@@ -0,0 +1,13 @@
+<!--
+	SPDX-FileCopyrightText: © 2025 Hornwitser <code@hornwitser.no>
+	SPDX-License-Identifier: AGPL-3.0-or-later
+-->
+# Sessions
+
+When a user creates a new account or logs in to an existing account a session is created on the server and linked to the user's browser via a session cookie. This cookie contains a unique identifier along with a HMAC signature created using the server's cookie secret key. Since this unique identifier stored on the user's device is a technical requirement to securely do what the user is requesting the user's consent to its storage can be assumed.
+
+Sessions have two future times associated with them: The expiration time is the point in time after the session will be recreated and the cookie reassigned, and the discard time is when the session is deleted from both the client and the server. The expiriation time is short, by default 1 hour, while the discard time is long, by default 2 weeks.
+
+When a request is made to a session that's past the expiration time a new session is created to replace the existing one, and the session cookie is updated with the new session. The purpose of this is to reduce the time window a stolen session can be used in without being detected. If a request is made using a session that has already been replaced the server responds with a message saying the "session has been taken".
+
+Sessions are created for a limited timespan, purpose and access level, and expires after the timespan is over, the purpose is fulfilled or the access level changes. For example if the user's account is promoted from regular to crew the session will no longer be valid and will be recreated as a new session with the new access level on the next request.