Auth

Part of the Sanchayam series. Invite-Only Signup Sanchayam is a personal finance tool. There is no public registration. New users are added by invitation from an existing user. The first user is created via a /setup endpoint that is only active when the database has no users. An invitation is a row in the invitations table: CREATE TABLE invitations ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), token_hash VARCHAR NOT NULL UNIQUE, label VARCHAR, email VARCHAR, expires_at TIMESTAMP NOT NULL, used_at TIMESTAMP, created_by UUID NOT NULL REFERENCES users(id), created_at TIMESTAMP NOT NULL DEFAULT NOW() ); The token itself is never stored - only its SHA-256 hash. The invitation link sent by email contains the raw token. When the signup form is submitted, the backend hashes the submitted token and looks up the hash. If the row exists, is not yet used, and has not expired, signup proceeds and used_at is set. The raw token cannot be reconstructed from the hash, so a database leak does not expose valid invitation links. ...

Part of the MediaBridge series. The Problem with Silent Token Refresh A 5-minute access token is short enough to be practical for security but creates a UX problem. When a page loads and fires several API calls simultaneously, the token might expire in the middle of that burst. Suddenly all five requests get a 401 TOKEN_EXPIRED at roughly the same time. The naive fix is to retry each 401 by refreshing the token. But if five requests all hit 401 and all try to refresh, you get five simultaneous calls to /auth/refresh. Refresh tokens are single-use. The first call succeeds and rotates the token. The next four present the now-used refresh token and get REFRESH_TOKEN_USED. Those requests fail and the user gets logged out, not because their session was invalid but because the client raced itself. ...