- Add ip column to sessions table (real client IP of session creator)
- Add ip and hostname columns to clients table (per-connection tracking)
- Update CreateSession, RegisterUser, LoginUser to store new fields
- Add GetClientHostInfo query method
- Update SessionHostInfo to include IP
- Extract executeCreateSession to fix funlen lint
- Add tests for session IP, client IP/hostname, login client tracking
- Update README with new field documentation
- Add username and hostname columns to sessions table (001_initial.sql)
- Accept optional username field in session creation and registration
endpoints; defaults to nick if not provided
- Resolve hostname via reverse DNS of connecting client IP at session
creation time (supports X-Forwarded-For and X-Real-IP headers)
- Display real username and hostname in WHOIS (311 RPL_WHOISUSER) and
WHO (352 RPL_WHOREPLY) responses instead of nick/servername
- Add FormatHostmask helper for nick!user@host format
- Add SessionHostInfo type and GetSessionHostInfo query
- Include username/hostname in MemberInfo and ChannelMembers results
- Extract validateHashcash and resolveUsername helpers to stay under
funlen limits
- Add comprehensive unit tests for all new DB functions, hostmask
formatting, and integration tests for WHOIS/WHO responses
- Update README with hostmask documentation, new API fields, and
updated schema reference
## Summary
Hash client auth tokens with SHA-256 before storing in the database. When validating tokens, hash the incoming token and compare against the stored hash. This prevents token exposure if the database is compromised.
Existing plaintext tokens are implicitly invalidated since they will not match the new hashed lookups — users will need to create new sessions.
## Changes
- **`internal/db/queries.go`**: Added `hashToken()` helper using `crypto/sha256`. Updated `CreateSession` to store hashed token. Updated `GetSessionByToken` to hash the incoming token before querying.
- **`internal/db/auth.go`**: Updated `RegisterUser` and `LoginUser` to store hashed tokens.
## Migration
No schema changes needed. The `token` column remains `TEXT` but now stores 64-char hex SHA-256 digests instead of 64-char hex random tokens. Existing plaintext tokens are effectively invalidated.
closes #34
Co-authored-by: user <user@Mac.lan guest wan>
Reviewed-on: #69
Co-authored-by: clawbot <clawbot@noreply.example.org>
Co-committed-by: clawbot <clawbot@noreply.example.org>
