feat: create server-side session validation SDK

[Soulike]

Summary

Create a server-side session validation SDK that allows backend services (e.g., admin-server) to validate sessions by calling the auth server's HTTP API, rather than reading Redis directly.

Motivation

Currently, admin-server-legacy validates sessions by directly reading from the shared Redis store. This couples it to auth server's internal implementation details (Redis, key format, JSON structure). If auth server changes its session storage, admin-server-legacy would break.

A server-side SDK would make auth server a black box — backend services only depend on the API contract (GET /session), not the internals.

Proposed Approach

Create a server-side session validation SDK (separate from @module/session-sdk which is browser-side):

• Package: e.g., @module/session-sdk-server or extend @module/session-sdk with server-compatible exports
• Function: validate a session by forwarding the cookie from an incoming request to GET /session on the auth server
• Usage: Koa middleware that extracts the sess cookie from the incoming request, calls auth server internally (e.g., http://auth-server:3000/session), and populates ctx.session
• Auth server URL: should be configurable (internal Docker network URL in production, not the public auth.soulike.tech)

Example usage in a Koa server

import {sessionValidator} from '@module/session-sdk-server';

app.use(sessionValidator({authServerUrl: 'http://auth-server:3000'}));
// ctx.session is now populated if valid, or null if not

Trade-offs

• Pro: Decouples backend services from auth server internals (Redis, session format)
• Pro: Auth server becomes a single source of truth for session management
• Con: Adds an HTTP round-trip per request (mitigated by internal Docker networking being fast)
• Con: Auth server becomes a critical dependency for all services

When to implement

When rewriting admin-server (non-legacy), this SDK should replace the direct Redis access pattern.

🤖 Generated with Claude Code