sneak/neoirc
1
0
Fork 0
Code Issues 3 Pull Requests 1 Actions 19 Packages Projects Releases Wiki Activity

Refuse a PRIVMSG or NOTICE whose body or meta has the wrong type (closes #245)
check / check (push) Canceled after 0s
Details

Browse Source 
Over the HTTP API, a PRIVMSG or NOTICE body was checked only by
decoding it into a list of strings. JSON null decodes into an empty
string there, and meta was not checked at all, so a null line, or a
meta that is not an object, reached every recipient.

handlePrivmsg now answers 400 invalid request body, before anything
else, when body is present and is not an array of strings, or meta is
present and is not an object. The check returns the lines it accepted,
and the empty-body check counts those, so body is decoded once. A
missing or empty body still gets ERR_NOTEXTTOSEND. README.md says so.

Model: opus-5-5
This commit was merged in pull request #247.
This commit is contained in:
clawbot
2026-11-02 07:39:17 +01:00
parent 562ce87245
commit 24e8b4d027
3 changed files with 209 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+12 -9
View File
@@ -643,8 +643,10 @@ Send a message to a channel or user. This is the primary messaging command.
message echoed back via the queue).
- If `to` is a bare nick, the message is a DM. The server fans out to the
recipient and the sender (so all of the sender's clients see the DM).
- `body` must be a non-empty array of strings; otherwise the server sends
ERR_NOTEXTTOSEND (412). A missing `to` gets ERR_NORECIPIENT (411).
- A `body` that is not an array of strings, or a `meta` that is not an object,
gets HTTP 400 `invalid request body`, and nothing is relayed. A missing or
empty `body` gets ERR_NOTEXTTOSEND (412). A missing `to` gets ERR_NORECIPIENT
(411).
- Only channel members can send to a channel. A non-member, a banned user, and
on a `+m` channel a user with neither `+o` nor `+v`, get ERR_CANNOTSENDTOCHAN
(404).
@@ -1749,17 +1751,18 @@ command). **Numeric replies**, for success and for errors, are delivered through
the message queue (see [Numeric Reply Codes](#numeric-reply-codes-s2c-only)); a
command that has none, such as a successful `PRIVMSG`, is answered by the HTTP
response alone, and `PING`'s `PONG` is the HTTP response body. HTTP error codes
(4xx/5xx) are reserved for transport-level problems: malformed JSON (400),
(4xx/5xx) are reserved for transport-level problems: a malformed request (400),
missing/invalid auth cookies (401), and server errors (500).
**HTTP errors (transport-level only):**
| Status | Error | When |
| ------ | ---------------------- | ------------------------------------------------------- |
| 400 | `invalid request body` | Malformed JSON, or a body over `MAX_MESSAGE_SIZE` bytes |
| 400 | `command required` | Empty command |
| 401 | `not registered` | Missing or invalid auth cookie |
| 500 | `internal error` | Server-side failure |
| Status | Error | When |
| ------ | ---------------------- | ------------------------------------------------------------------------------------------------- |
| 400 | `invalid request body` | Malformed JSON, or a body over `MAX_MESSAGE_SIZE` bytes |
| 400 | `invalid request body` | A `PRIVMSG` or `NOTICE` whose `body` is not an array of strings, or whose `meta` is not an object |
| 400 | `command required` | Empty command |
| 401 | `not registered` | Missing or invalid auth cookie |
| 500 | `internal error` | Server-side failure |
**IRC numeric error replies (delivered via message queue):**