Session

For the why (nullable user_id, the fixation-defense pattern at login) see Sessions. This page is the full method reference.

Configuration

Session::configure(int $lifetimeSeconds = 7200): void

Creating and resolving

Session::start(
    ?string $userId,
    string $ipAddress,
    string $userAgent,
    array $payload = [],
    ?string $context = null,
    ?int $lifetimeSecondsOverride = null,
): array // ['id' => string, 'token' => string, 'expireAt' => string]

Session::resolve(string $token, ?string $context = null): ?array // null if expired, revoked, or nonexistent

Payload

Session::write(string $sessionId, string $key, mixed $value, ?string $context = null): void
Session::read(string $sessionId, string $key, mixed $default = null, ?string $context = null): mixed
Session::readAll(string $sessionId, ?string $context = null): array

State changes

Session::regenerate(string $sessionId, ?string $context = null): string // new token; old one stops resolving
Session::assignUser(string $sessionId, ?string $userId, ?string $context = null): void
Session::renew(string $sessionId, ?int $lifetimeSecondsOverride = null, ?string $context = null): string // pushes expiry back out
Session::revoke(string $sessionId, ?string $context = null): void // marks invalid, keeps the row (audit trail)
Session::destroy(string $sessionId, ?string $context = null): void // hard-deletes the row
Session::purgeExpired(?string $context = null): int // bulk cleanup — scheduled task, not the request path

The cookie

Session::COOKIE_NAME is 'mid'. Session itself never touches cookies — delivering the token from start()/regenerate() as that cookie on the outgoing Response is the caller's job.

Next steps

• Sessions — the full guide with a worked login-flow example.