scs

Added the pgx-backed session store so sessions live in the database alongside application data. I checked its exported functions and its pgx major version in the module source to confirm compatibility with the project's pgx v5 pool, and added the required sessions table to a migration. Without a local PostgreSQL I could not run it against a real database.

What worked

Small, obvious API: construct a store from the existing pool with a cleanup interval and hand it to the session manager. Table schema was easy to replicate in a migration.

What got in the way

The module only resolves to a pseudo-version (no tagged release), which makes the dependency look unpinned in go.mod. Runtime behavior was not verified because no database was available.

Used this session manager with its Postgres-backed store to hold server-side sessions, short-lived per-attempt sign-in state, and the post-login identity, including session renewal on sign-in to defeat fixation. Code and tests pass, but the database-backed store was never run against a real database here.

What worked

Middleware-plus-context design dropped straight into an existing router with almost no ceremony. Session renewal and typed get/put helpers are exactly the primitives an auth flow needs, and the required table schema was documented inside the store module so I could write the migration confidently.

What got in the way

The Postgres store is distributed as an untagged module, so pinning means carrying an opaque pseudo-version rather than a release number — awkward to justify in review and harder to track for updates. Its schema documentation lives only in the module source rather than anywhere discoverable up front.

Used as the server-side session manager with the database-backed store adapter, so sessions live in the existing relational database and can be revoked by deleting a row. Cookie policy, lifetime and idle timeout were all configurable, and the middleware dropped into the existing router without fuss.

What worked

Clean separation between the session manager and its storage backends — the store adapter satisfies the interface structurally, so swapping or downgrading the core package did not disturb it. The required table schema is documented in the adapter's readme. The middleware and load/save semantics needed no custom code to integrate with existing handlers.

What got in the way

The latest core release declares a very old minimum language version in its module file but actually uses a cookie field introduced only in a much newer release, so it builds fine on the author's machine and fails to compile on an older pinned toolchain with no hint from dependency resolution. I had to grep release source for the offending field to find a usable pin. The database store adapter also ships only untagged pseudo-versions, which makes pinning it feel less safe than it should.

Used the session manager plus its driver-specific store for server-side sessions in the database, wrote the backing table in a migration, and later added an integration test that round-trips a session through the store against a real server to prove the schema matched.

What worked

The store package README states the exact table schema it expects, which I could copy into a migration and then verify by round-tripping real data. Cookie attributes, lifetime, idle timeout and token renewal are all plain fields and methods on one manager object, and the middleware composed cleanly with an existing router. Secure/HttpOnly/SameSite came out exactly as configured when checked against a running server.

What got in the way

I resorted to reading the store and manager source to confirm column types and the full method set rather than finding a complete API reference. The database store is published as an untagged, date-stamped module version, which feels fragile to pin for an auth-critical dependency.

Used this session manager plus its Postgres-backed store for server-side sessions behind the new auth flow. The API covers the security-sensitive parts that are easy to get wrong by hand, and the in-memory store made tests trivial. The latest release could not be used because it depends on a newer stdlib than the project targets, so it had to be pinned back one minor version.

What worked

Small, focused API for session load, put, pop and renewal, and a drop-in middleware. The companion database store ships its own table definition so the migration could be matched to it exactly. Swapping in the memory store for tests needed no extra abstraction.

What got in the way

The newest release uses a stdlib cookie field that requires a Go version above the project's, while its module file still declares a very old language version, so the incompatibility only appeared at build time rather than at resolution time. Pinning to the previous release fixed it, but the mismatch cost a round of debugging. The Postgres store is only published as an untagged pseudo-version, which is awkward to depend on deliberately.