agentsclimarketplace
Sign in

Session management

Skill Amey-Thakur/AI-SKILLS/skills/security/session-management

Handle sessions so identifiers rotate on privilege change, expire on inactivity, can be revoked server-side, and ride only on hardened cookies. Use when issuing, storing, or validating session tokens after a user signs in.From its SKILL.md

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill session-management

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.0 KB, 641 tokens by cl100k_base, as published. Nobody here has run it

Session management

A session is the credential a user carries after login, so a stolen or stale session is a stolen identity. The dangers are a token that never dies, one that survives a password change, and one exposed to script or sent in the clear. Good session handling is about controlling the token's lifetime and reach.

Method

  1. Set the cookie flags that lock the token down. Mark session cookies HttpOnly (script cannot read them), Secure (HTTPS only), and SameSite=Lax or Strict (limits cross-site sending). Scope with Path and avoid a wildcard Domain. These four attributes block the cheapest theft routes.
  2. Rotate the session ID on every privilege change. Issue a new identifier at login, at logout, and when a user elevates (assumes admin, re-authenticates for a sensitive action). Rotation defeats fixation and shrinks the window a captured pre-elevation token is worth anything.
  3. Expire on both idle and absolute timeouts. Enforce an inactivity timeout (for example 30 minutes) and a hard maximum lifetime (8 to 24 hours) after which re-login is required regardless of activity. A token that lives forever is a permanent key once copied.
  4. Store sessions server-side so you can revoke them. Keep a server record (a session store, Redis, a table) keyed by an opaque random ID, so logout, a password reset, or an admin action can delete it and end the session at once. If you use stateless JWTs, add a revocation list or keep lifetimes very short, because a plain JWT cannot be recalled.
  5. Generate identifiers from a CSPRNG. Use at least 128 bits from a cryptographically secure source (secrets.token_urlsafe, crypto.randomBytes), not a counter, a timestamp, or Math.random. A guessable session ID is an open door that needs no theft.
  6. Invalidate sessions on the events that demand it. On logout, delete the server record, do not just clear the cookie. On password change or reset, revoke that user's other sessions so a thief already inside is evicted.

Checks

  • Do the response headers show HttpOnly, Secure, and SameSite on the session cookie?
  • After a password reset, are the user's other active sessions rejected on their next request?
  • Does an idle session stop working after the timeout, verified by waiting past it?

Boundaries

Session management picks up after authentication succeeds and hands off to authorization for per-request access decisions. It does not cover the login flow itself (see authn-design) or token-based API patterns like OAuth bearer tokens, whose lifecycle differs. Framework session middleware handles most of this correctly; the risk is in overrides and custom stores.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most auth identity skills give in 641 tokens

Counted across 408 of the 432 authors here whose files we hold, read 2026-09-06

  • Use parameterized queries for all SQL and database access to prevent SQL injectionin 60 of 408, across 40 files
  • Hash passwords with bcrypt or Argon2idin 50 of 408, across 34 files
  • Store secrets in Vault or environment variablesin 37 of 408, across 17 files
  • Add security headers to all responsesin 28 of 408, across 14 files
  • Rate limit public endpoints per clientin 22 of 408, across 8 files
  • Store tokens in httpOnly cookiesin 21 of 408, across 16 files
  • Use HTTPS in productionin 17 of 408, across 4 files
  • Apply rate limiting to all API endpointsin 17 of 408, across 9 files
  • Validate all input with Bean Validationin 16 of 408, across 3 files
  • Enable JWT or OIDC for stateless authenticationin 15 of 408, across 2 files
  • Scan dependencies for CVEsin 15 of 408, across 2 files
  • Log audit records for sensitive operationsin 15 of 408, across 2 files

Said here and by no other author read

  • Scope cookies with a narrow Path
  • Rotate session ID on login, logout, and elevation
  • Store sessions server-side keyed by opaque random ID
  • Generate session IDs from a CSPRNG
  • Use at least 128 bits of entropy
  • Add a revocation list for stateless JWTs

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.