-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ban redirects are not applied in other channels on $j
extbans
#316
Comments
As a workaround, you can set the |
Yep, that's the workaround I mentioned at the end, although it requires one ban list channel per redirect target. We had multiple for different circumstances so far, e.g. quit/join spamming to one channel, questionable connections to one, and undesired users to another (or just banned entirely). That's too annoying, so we're collapsing it into one, which is fine but still a bit unfortunate. |
The workaround you mentioned is different; you're setting the forward in the
|
Oh, I misread that. Brilliant, thanks for the idea! |
Setup:
#channel0
: a redirecting ban, e.g.+b nick!*@*$#channel2
#channel1
: a$j
extban:+b $j:#channel0
When
nick
now joins#channel1
, they simply getERR_BANNEDFROMCHAN
. The intuitive expectation is that they would get redirected to#channel2
.The real-world use case for this behaviour is effective and efficient cross-channel bans. With dozens of channels, keeping their ban lists synchronised is just not going to happen. So we instead want to have one single source of truth for 'global' bans and then apply them everywhere via
$j
extbans in the rest of the channels. In some cases, we'd want this to be a straight ban, which works correctly. But in others, we want to redirect the users to a certain separate channel, e.g. when they're spamming the channels with quit/rejoin messages due to a network issues. The above setup is what we believed to work correctly, only to realise that it actually only does the right thing when the user joins#channel0
.This was discovered on hackint, which still runs Charybdis, but if I'm reading the code correctly, Solanum should behave exactly the same way. The canjoin extban calls
is_banned
, which handles the bans and also returns the forward channel if the last argument is non-NULL
, but the canjoin extban extension calls it withNULL
and thus never knows about the forwarding:solanum/extensions/extb_canjoin.c
Line 66 in 22ebfd2
The extban extension is called from
is_banned_list
itself, so it shouldn't be too difficult to add a forward target pointer there and pass the information back tocan_join
andcheck_forward
that way.As a workaround, we're now switching to a setup where we use a normal ban in
#channel0
and a redirecting extban$j:#channel0$#channel2
in#channel1
. This unfortunately means it's not possible to differentiate whether or where people get redirected; everyone banned from#channel0
ends up in#channel2
(unless they're banned there as well).The text was updated successfully, but these errors were encountered: