Ban redirects are not applied in other channels on $j extbans #316
Description
Setup:
#channel0: a redirecting ban, e.g.+b nick!*@*$#channel2#channel1: a$jextban:+b $j:#channel0
When nick now joins #channel1, they simply get ERR_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 with NULL 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 to can_join and check_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).