Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
1aa77e1bad |
@@ -1266,12 +1266,6 @@ IRC listener sends the usual 3-digit code. Over the HTTP API, 005 arrives named
|
||||
| `501` | ERR_UMODEUNKNOWNFLAG | User mode not accepted | `{"command":"ERR_UMODEUNKNOWNFLAG","code":501,"to":"alice","body":["Unknown MODE flag"]}` |
|
||||
| `502` | ERR_USERSDONTMATCH | User MODE for another nick | `{"command":"ERR_USERSDONTMATCH","code":502,"to":"alice","body":["Can't change mode for other users"]}` |
|
||||
|
||||
**Note:** Numeric replies are now implemented. All IRC command responses
|
||||
(success and error) are delivered as numeric replies through the message queue.
|
||||
HTTP error codes are reserved for transport-level issues (auth failures,
|
||||
malformed requests, server errors). The `params` field in the message envelope
|
||||
carries IRC-style parameters (e.g., channel name, target nick).
|
||||
|
||||
### Channel Modes
|
||||
|
||||
Inspired by IRC, simplified. See [MODE](#mode--query-and-change-modes) for how
|
||||
@@ -2421,7 +2415,7 @@ applied; `001_initial.sql` creates the tables below.
|
||||
| `signing_key` | TEXT | Public signing key; nothing sets or reads it yet |
|
||||
| `away_message` | TEXT | Away message (empty string if not away) |
|
||||
| `created_at` | DATETIME | Session creation time |
|
||||
| `last_seen` | DATETIME | Last login or authenticated HTTP API request |
|
||||
| `last_seen` | DATETIME | Last login or authenticated HTTP API request (or creation) |
|
||||
|
||||
Index on `(uuid)`.
|
||||
|
||||
@@ -3163,11 +3157,11 @@ When the limit is exceeded, the server returns **429 Too Many Requests** with a
|
||||
> targeted attack.
|
||||
|
||||
**Why rate limits here but not on session creation?** Session creation is
|
||||
protected by hashcash proof-of-work (stateless, no IP tracking needed). Login
|
||||
involves bcrypt password verification against a registered account — a
|
||||
fundamentally different threat model where an attacker targets a specific
|
||||
account. Per-IP rate limiting is appropriate here because the cost of a wrong
|
||||
guess is borne by the server (bcrypt), not the client.
|
||||
protected by hashcash proof-of-work (no IP tracking needed). Login involves
|
||||
bcrypt password verification against a registered account — a fundamentally
|
||||
different threat model where an attacker targets a specific account. Per-IP rate
|
||||
limiting is appropriate here because the cost of a wrong guess is borne by the
|
||||
server (bcrypt), not the client.
|
||||
|
||||
---
|
||||
|
||||
@@ -3222,8 +3216,8 @@ guess is borne by the server (bcrypt), not the client.
|
||||
331-332 TOPIC, 352-353 WHO/NAMES, 366, 372-376 MOTD, 401-502 errors)
|
||||
- [x] **Max message size enforcement** — reject request bodies over
|
||||
`MAX_MESSAGE_SIZE` bytes
|
||||
- [x] **NOTICE command** — distinct from PRIVMSG (no RPL_AWAY, no hashcash
|
||||
check)
|
||||
- [x] **NOTICE command** — distinct from PRIVMSG over the HTTP API (no RPL_AWAY,
|
||||
no hashcash check)
|
||||
- [x] **Multi-client sessions** — set a password via PASS command, then login
|
||||
from additional devices via `POST /api/v1/login`
|
||||
- [x] **Cookie-based auth** — HttpOnly cookies replace Bearer tokens for all API
|
||||
|
||||
Reference in New Issue
Block a user