Open JustAnotherArchivist opened 8 months ago
for what it's worth, the reason this happens is "is this user banned in this channel" is a cached decision and the cache is only updated in a set number of occasions. setting a ban on a $j:
downstream is not one of those occasions
Setup:
#channel
has a ban on$j:#bans
. A user with nickname Eve is already in#channel
, then a ban forEve!*@*
is applied in#bans
.Expected behaviour: Once the ban is in place, Eve cannot send messages (
PRIVMSG
orNOTICE
) to#channel
anymore and gets anERR_CANNOTSENDTOCHAN
instead.Actual behaviour: If Eve had already sent a message to the channel before the ban was added, messages are not blocked until the ban list of
#channel
is modified.The same behaviour is also observed if
#channel
has+q $j:#bans
rather than+b
. Based on my reading of the code,+e
might also be affected, though I haven't tested this.Transcript of a reproduction against Solanum commit 1ccc6422. Each protocol line is prefixed with the originating user (Bob for the channel admin, Eve as above) and the direction (
>
for lines sent by the client,<
for received lines). I've omitted the obvious replies (001, join and mode confirmation, etc.).I found this last night while fighting a spammer, thinking a single ban in the central channel should quiet them globally (with
$j
bans everywhere else already in place). It appears that that's currently impossible if they've already sent messages; instead, you have to do something to each channel they're in, e.g. apply any ban/quiet there or kick them.I suspect that this is due to the caching in
can_send
. Upon adding a ban, thebants
cache needs to be invalidated not only in that channel but also in any channel that embeds its ban list via$j
extbans. The latter part is what appears to be missing.