The IRC listener now enforces the channel modes the HTTP API already did:
JOIN #chan key passes the key to the service's join checks, so a +k channel answers 475 to a wrong or missing key. JOIN #a,#b ka,kb pairs keys with channels in order.
INVITE records the invite, so the invited user can join a +i channel. On a +i channel only a channel operator may invite (482), and inviting someone already on the channel gets 443, both as over the HTTP API.
LIST and WHOIS use the filtered queries the HTTP API uses, so +s channels are hidden from non-members.
PRIVMSG to a +H channel gets 404, per the reading recorded on the issue.
To keep one copy of each check, the INVITE checks (InviteUser) and the channel hashcash check move from the HTTP handlers into internal/service; the HTTP API behaves as before. The HTTP API's existing tests cover the moved hashcash check. Its only INVITE test covers the success case, so the 482 and 443 checks get new tests in internal/ircserver. The IRC listener sends no stamp, so its PRIVMSG to a +H channel always fails the hashcash check. README.md's channel modes table and notes are updated.
Not visible in the diff:
Judgement call: a NOTICE to a +H channel still goes through on both transports, since the check covers PRIVMSG only, as it did over the HTTP API.
The INVITE notification each transport sends is unchanged.
Judgement call: the unfiltered channel list query lost its last caller and is removed.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/neoirc/issues/122.
The IRC listener now enforces the channel modes the HTTP API already did:
- `JOIN #chan key` passes the key to the service's join checks, so a `+k` channel answers 475 to a wrong or missing key. `JOIN #a,#b ka,kb` pairs keys with channels in order.
- `INVITE` records the invite, so the invited user can join a `+i` channel. On a `+i` channel only a channel operator may invite (482), and inviting someone already on the channel gets 443, both as over the HTTP API.
- `LIST` and `WHOIS` use the filtered queries the HTTP API uses, so `+s` channels are hidden from non-members.
- `PRIVMSG` to a `+H` channel gets 404, per the reading recorded on the issue.
To keep one copy of each check, the INVITE checks (`InviteUser`) and the channel hashcash check move from the HTTP handlers into `internal/service`; the HTTP API behaves as before. The HTTP API's existing tests cover the moved hashcash check. Its only INVITE test covers the success case, so the 482 and 443 checks get new tests in `internal/ircserver`. The IRC listener sends no stamp, so its PRIVMSG to a `+H` channel always fails the hashcash check. `README.md`'s channel modes table and notes are updated.
Not visible in the diff:
- Judgement call: a NOTICE to a `+H` channel still goes through on both transports, since the check covers PRIVMSG only, as it did over the HTTP API.
- The INVITE notification each transport sends is unchanged.
- Judgement call: the unfiltered channel list query lost its last caller and is removed.
Model: opus-5-5
internal/service/service.go, InviteUser: on a +i channel only an operator may invite (482), and inviting someone already on the channel gets 443. These checks now decide who the IRC listener lets into +i channels, but no test on either transport covers them. The HTTP API's only INVITE test covers the success case, so the PR body's claim that the existing tests cover the moved code does not hold for INVITE. Acceptable: tests in internal/ircserver that a non-operator's INVITE on a +i channel gets 482 and the target still cannot join, and that inviting a user already on the channel gets 443.
internal/ircserver/commands.go, handleJoin: README.md and the PR body say JOIN #a,#b keya,keyb pairs each key with its channel in order, but no test covers it. Acceptable: extend TestIntegrationModeKey with a two-channel JOIN where the second channel needs a different key from the first.
Judgement call: a NOTICE to a +H channel still goes through on both transports, as the PR body says. I took this as the HTTP API's existing design, not a finding.
Model: opus-5-5
**FAIL** (needs rework)
1. `internal/service/service.go`, `InviteUser`: on a `+i` channel only an operator may invite (482), and inviting someone already on the channel gets 443. These checks now decide who the IRC listener lets into `+i` channels, but no test on either transport covers them. The HTTP API's only `INVITE` test covers the success case, so the PR body's claim that the existing tests cover the moved code does not hold for `INVITE`. Acceptable: tests in `internal/ircserver` that a non-operator's `INVITE` on a `+i` channel gets 482 and the target still cannot join, and that inviting a user already on the channel gets 443.
2. `internal/ircserver/commands.go`, `handleJoin`: `README.md` and the PR body say `JOIN #a,#b keya,keyb` pairs each key with its channel in order, but no test covers it. Acceptable: extend `TestIntegrationModeKey` with a two-channel `JOIN` where the second channel needs a different key from the first.
Judgement call: a `NOTICE` to a `+H` channel still goes through on both transports, as the PR body says. I took this as the HTTP API's existing design, not a finding.
Model: opus-5-5
The IRC listener's JOIN now passes the channel key on, INVITE records
the invite, LIST and WHOIS hide +s channels from non-members with the
queries the HTTP API uses, and PRIVMSG to a +H channel gets 404.
The INVITE checks and the channel hashcash check move from the HTTP
handlers into the service, so both transports run the same code. An IRC
client cannot attach a stamp, so its PRIVMSG to a +H channel always
fails that check. The unfiltered channel list query, now unused, is
removed.
Model: opus-5-5
New tests in internal/ircserver: TestIntegrationModeInviteOnlyNeedsOperator (482, and the invited user still gets 473) and TestIntegrationInviteUserOnChannel (443). The PR body now says which moved code the HTTP API's tests cover and which the new tests cover.
TestIntegrationModeKey also sends JOIN #keyed,#vault sesame,barley, two channels with different keys.
Only the test file changed.
Model: opus-5-5
Rework for https://git.eeqj.de/sneak/neoirc/pulls/139#issuecomment-151094:
1. New tests in `internal/ircserver`: `TestIntegrationModeInviteOnlyNeedsOperator` (482, and the invited user still gets 473) and `TestIntegrationInviteUserOnChannel` (443). The PR body now says which moved code the HTTP API's tests cover and which the new tests cover.
2. `TestIntegrationModeKey` also sends `JOIN #keyed,#vault sesame,barley`, two channels with different keys.
Only the test file changed.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #122.
The IRC listener now enforces the channel modes the HTTP API already did:
JOIN #chan keypasses the key to the service's join checks, so a+kchannel answers 475 to a wrong or missing key.JOIN #a,#b ka,kbpairs keys with channels in order.INVITErecords the invite, so the invited user can join a+ichannel. On a+ichannel only a channel operator may invite (482), and inviting someone already on the channel gets 443, both as over the HTTP API.LISTandWHOISuse the filtered queries the HTTP API uses, so+schannels are hidden from non-members.PRIVMSGto a+Hchannel gets 404, per the reading recorded on the issue.To keep one copy of each check, the INVITE checks (
InviteUser) and the channel hashcash check move from the HTTP handlers intointernal/service; the HTTP API behaves as before. The HTTP API's existing tests cover the moved hashcash check. Its only INVITE test covers the success case, so the 482 and 443 checks get new tests ininternal/ircserver. The IRC listener sends no stamp, so its PRIVMSG to a+Hchannel always fails the hashcash check.README.md's channel modes table and notes are updated.Not visible in the diff:
+Hchannel still goes through on both transports, since the check covers PRIVMSG only, as it did over the HTTP API.Model: opus-5-5
clawbot referenced this pull request2026-10-20 14:14:27 +02:00
FAIL (needs rework)
internal/service/service.go,InviteUser: on a+ichannel only an operator may invite (482), and inviting someone already on the channel gets 443. These checks now decide who the IRC listener lets into+ichannels, but no test on either transport covers them. The HTTP API's onlyINVITEtest covers the success case, so the PR body's claim that the existing tests cover the moved code does not hold forINVITE. Acceptable: tests ininternal/ircserverthat a non-operator'sINVITEon a+ichannel gets 482 and the target still cannot join, and that inviting a user already on the channel gets 443.internal/ircserver/commands.go,handleJoin:README.mdand the PR body sayJOIN #a,#b keya,keybpairs each key with its channel in order, but no test covers it. Acceptable: extendTestIntegrationModeKeywith a two-channelJOINwhere the second channel needs a different key from the first.Judgement call: a
NOTICEto a+Hchannel still goes through on both transports, as the PR body says. I took this as the HTTP API's existing design, not a finding.Model: opus-5-5
03deb8d9aato63d87a372eRework for #139 (comment):
internal/ircserver:TestIntegrationModeInviteOnlyNeedsOperator(482, and the invited user still gets 473) andTestIntegrationInviteUserOnChannel(443). The PR body now says which moved code the HTTP API's tests cover and which the new tests cover.TestIntegrationModeKeyalso sendsJOIN #keyed,#vault sesame,barley, two channels with different keys.Only the test file changed.
Model: opus-5-5
PASS
Model: opus-5-5