0003012: Ability to sqline channels. - UnrealIRCd Bug Tracker

(0012124)
codemastr (reporter)
2006-08-02 22:58

What's the point of this?

(0012126)
Jase (reporter)
2006-08-03 04:24

So that Service Administrators could close a channel, and stop it from being used all together, without having to go to the Server Administrator and asking for particular 'trouble making' channels to be added to the deny block.

It was just a thought.

(0012130)
aquanight (reporter)
2006-08-03 12:04

I could be wrong but doesn't ChanServ usually have a FORBID command that usually works quite as well? (although sqline the channel would make it easier/better ("Cannot join channel (<forbid reason>)" as opposed to "Cannot join channel (+b)") for services to enforce the forbid rather than have a service bot squat the channel)

(0012131)
Jase (reporter)
2006-08-03 12:58

I've tried chanserv forbid, but it doesn't seem to have the same effect.
Users can still join the channel, and then they instantly get kicked out, but they don't seem to be banned, so they get kicked, and kicked again, and so on, til they stop trying to join.

In the case where there are lots of drones/bots, it would cause a load on services for each channel that is forbidden.

That is why I thought support for sqlining channels would make things easier in that respect.

(0012143)
tabrisnet (reporter)
2006-08-03 19:40

True, but that's about as much about anope's bad implementation of the command. What it should do is JOIN ChanServ, BAN *!*@*, KICK, and have ChanServ sit for 60 seconds.
As it is, I'm not sure if it sits or not (been a while since I looked), and I know that it doesn't ban *!*@* but rather just that one host for that user.
And if you set it +s and sit a bot in there, the banlist just gets bigger.

(0012146)
djGrrr (reporter)
2006-08-03 22:01

That would also ban opers from the channel (minus a sajoin)
The ability to deny a channel without editing the conf file would be very useful and a good feature

(0012147)
tabrisnet (reporter)
2006-08-03 22:47

a) why do opers need to step into a forbidden chan. nothing is in there
b) If you have a bot in there, you can have IT invite you
c) If you don't have a bot in there, you can still use any of sajoin, banwalk (OperOverride INVITE, then JOIN), or CS INVITE
d) having the banlist grow to 60+ isn't that good either, esp if the ban list fills and then can't keep growing, so that the ban is no longer effective

(0012148)
tabrisnet (reporter)
2006-08-03 22:48

Oh yeah. and if this DOES happen, I would hope it would become a new type of *line, not a qline. Talk about breaking existing code...
Why not make a new TKL C or something.

(0012153)
White_Magic (reporter)
2006-08-04 21:52

wot happens if, a ircop adds a channel sqline and there are bots inside it?
say theres 1000 bots
thats a nice flood the server has to generate to kick them or so

(0012154)
tabrisnet (reporter)
2006-08-04 22:02

Point... otoh, an sqline doesn't force the user to change their nick, it just prevents others from changing to it.
You could argue that a channel block would prevent joins.

And tbh, if you do a FORBID or CLOSE or w/e with services, it would cause the same 'flood'.

I'm not necessarily against the idea, but would want it to be done in a proper way that means, to me, NOT a TKL Q or SQLINE. if it must be TKL, make it a new type. alternatively consider a new cmd, like SVSFLINE (in this case, SVSCLINE or something)

(0012169)
w00t (reporter)
2006-08-11 12:36

(I'll quietly note that if you're worried about this breaking existing code (I presume with your services?) you are making assumptions you shouldn't be. I'm pretty sure bahamut allows for channel-based Q:.)

(0012170)
tabrisnet (reporter)
2006-08-11 12:58

for SQLINE, sure. for TKL Q... I'll leave that to your imagination.
otoh, I don't have to parse SQLINE as I'll never see it. Only generate it.

meanwhile, if it's gonna become a TKL event, it should be its own. I see it specifically as being different.

(0012173)
w00t (reporter)
2006-08-11 15:38

BD + Q * #warez w00t 1234 1234 :Fuckers.

Not sure that's fully valid (hey, my UnProtoCol SkiLlZ are rusty), but I fail to see how that's drastically difficult to parse?

You'll never recieve a NICK with a # as the first character, so even if you were doing something bizarre and fucked up with it, nothing would break. So, bahamut-alike behaviour still looks valid

(0012178)
tabrisnet (reporter)
2006-08-13 15:58

I'm just not wanting more special cases in the code if I can avoid it. Esp if I had to start having my code be aware of what qlines actually do/mean (which, at present, it does not)

(0012182)
djGrrr (reporter)
2006-08-16 09:03

i don't see why you would need to put any special cases in the code at all, you
d simply check for a q:line on the nick / channel, there would be no need for checking if # is the first character or anything like that, # is not gonna be the first char in a nick, just like channels will always start with #, so just checking for a q:line would not need anything at all special, because when u check for a channel q:line, it can't match a nick q:line as it won't be prefixed by #; i honestly can't see any reason not to use a q:line for both.

(0012183)
aquanight (reporter)
2006-08-16 09:59

Unless you get wildcards involved. Then you get fun things like *hello* bans both nicks and channels. No it'd probably more like: if the mask starts with a #, it's a channel ban, and if it doesn't, it's not.

(0012184)
djGrrr (reporter)
2006-08-16 10:13

yeah, i actually thought about that after i posted, hmmm, there has to be an easy way to do it, while still keeping the same tkl

(0012947)
Trocotronic (reporter)
2006-12-28 12:31

Fixed in .2320

Issue History
Date Modified	Username	Field	Change
2006-08-01 11:56	Jase	New Issue
2006-08-02 22:58	codemastr	Note Added: 0012124
2006-08-03 04:24	Jase	Note Added: 0012126
2006-08-03 12:04	aquanight	Note Added: 0012130
2006-08-03 12:58	Jase	Note Added: 0012131
2006-08-03 19:40	tabrisnet	Note Added: 0012143
2006-08-03 19:40	tabrisnet	Issue Monitored: tabrisnet
2006-08-03 22:01	djGrrr	Note Added: 0012146
2006-08-03 22:47	tabrisnet	Note Added: 0012147
2006-08-03 22:48	tabrisnet	Note Added: 0012148
2006-08-04 10:41	White_Magic	Issue Monitored: White_Magic
2006-08-04 21:52	White_Magic	Note Added: 0012153
2006-08-04 22:02	tabrisnet	Note Added: 0012154
2006-08-11 12:36	w00t	Note Added: 0012169
2006-08-11 12:58	tabrisnet	Note Added: 0012170
2006-08-11 15:38	w00t	Note Added: 0012173
2006-08-13 15:58	tabrisnet	Note Added: 0012178
2006-08-16 09:03	djGrrr	Note Added: 0012182
2006-08-16 09:59	aquanight	Note Added: 0012183
2006-08-16 10:13	djGrrr	Note Added: 0012184
2006-11-12 15:18	syzop	Relationship added	child of 0003049
2006-12-01 12:59	syzop	Relationship added	has duplicate 0000935
2006-12-28 12:31	Trocotronic	Status	new => resolved
2006-12-28 12:31	Trocotronic	Fixed in Version	=> 3.3-alpha0
2006-12-28 12:31	Trocotronic	Resolution	open => fixed
2006-12-28 12:31	Trocotronic	Assigned To	=> Trocotronic
2006-12-28 12:31	Trocotronic	Note Added: 0012947
2007-03-26 03:15	tabrisnet	Issue End Monitor: tabrisnet
2010-07-02 10:22	syzop	Relationship added	parent of 0003915

Notes
(0012124) codemastr (reporter) 2006-08-02 22:58	What's the point of this?

(0012126) Jase (reporter) 2006-08-03 04:24	So that Service Administrators could close a channel, and stop it from being used all together, without having to go to the Server Administrator and asking for particular 'trouble making' channels to be added to the deny block. It was just a thought.

(0012130) aquanight (reporter) 2006-08-03 12:04	I could be wrong but doesn't ChanServ usually have a FORBID command that usually works quite as well? (although sqline the channel would make it easier/better ("Cannot join channel (<forbid reason>)" as opposed to "Cannot join channel (+b)") for services to enforce the forbid rather than have a service bot squat the channel)

(0012131) Jase (reporter) 2006-08-03 12:58	I've tried chanserv forbid, but it doesn't seem to have the same effect. Users can still join the channel, and then they instantly get kicked out, but they don't seem to be banned, so they get kicked, and kicked again, and so on, til they stop trying to join. In the case where there are lots of drones/bots, it would cause a load on services for each channel that is forbidden. That is why I thought support for sqlining channels would make things easier in that respect.

(0012143) tabrisnet (reporter) 2006-08-03 19:40	True, but that's about as much about anope's bad implementation of the command. What it should do is JOIN ChanServ, BAN !@, KICK, and have ChanServ sit for 60 seconds. As it is, I'm not sure if it sits or not (been a while since I looked), and I know that it doesn't ban !@ but rather just that one host for that user. And if you set it +s and sit a bot in there, the banlist just gets bigger.

(0012146) djGrrr (reporter) 2006-08-03 22:01	That would also ban opers from the channel (minus a sajoin) The ability to deny a channel without editing the conf file would be very useful and a good feature

(0012147) tabrisnet (reporter) 2006-08-03 22:47	a) why do opers need to step into a forbidden chan. nothing is in there b) If you have a bot in there, you can have IT invite you c) If you don't have a bot in there, you can still use any of sajoin, banwalk (OperOverride INVITE, then JOIN), or CS INVITE d) having the banlist grow to 60+ isn't that good either, esp if the ban list fills and then can't keep growing, so that the ban is no longer effective

(0012148) tabrisnet (reporter) 2006-08-03 22:48	Oh yeah. and if this DOES happen, I would hope it would become a new type of *line, not a qline. Talk about breaking existing code... Why not make a new TKL C or something.

(0012153) White_Magic (reporter) 2006-08-04 21:52	wot happens if, a ircop adds a channel sqline and there are bots inside it? say theres 1000 bots thats a nice flood the server has to generate to kick them or so

(0012154) tabrisnet (reporter) 2006-08-04 22:02	Point... otoh, an sqline doesn't force the user to change their nick, it just prevents others from changing to it. You could argue that a channel block would prevent joins. And tbh, if you do a FORBID or CLOSE or w/e with services, it would cause the same 'flood'. I'm not necessarily against the idea, but would want it to be done in a proper way that means, to me, NOT a TKL Q or SQLINE. if it must be TKL, make it a new type. alternatively consider a new cmd, like SVSFLINE (in this case, SVSCLINE or something)

(0012169) w00t (reporter) 2006-08-11 12:36	(I'll quietly note that if you're worried about this breaking existing code (I presume with your services?) you are making assumptions you shouldn't be. I'm pretty sure bahamut allows for channel-based Q:.)

(0012170) tabrisnet (reporter) 2006-08-11 12:58	for SQLINE, sure. for TKL Q... I'll leave that to your imagination. otoh, I don't have to parse SQLINE as I'll never see it. Only generate it. meanwhile, if it's gonna become a TKL event, it should be its own. I see it specifically as being different.

(0012173) w00t (reporter) 2006-08-11 15:38	BD + Q * #warez w00t 1234 1234 :Fuckers. Not sure that's fully valid (hey, my UnProtoCol SkiLlZ are rusty), but I fail to see how that's drastically difficult to parse? You'll never recieve a NICK with a # as the first character, so even if you were doing something bizarre and fucked up with it, nothing would break. So, bahamut-alike behaviour still looks valid

(0012178) tabrisnet (reporter) 2006-08-13 15:58	I'm just not wanting more special cases in the code if I can avoid it. Esp if I had to start having my code be aware of what qlines actually do/mean (which, at present, it does not)

(0012182) djGrrr (reporter) 2006-08-16 09:03	i don't see why you would need to put any special cases in the code at all, you d simply check for a q:line on the nick / channel, there would be no need for checking if # is the first character or anything like that, # is not gonna be the first char in a nick, just like channels will always start with #, so just checking for a q:line would not need anything at all special, because when u check for a channel q:line, it can't match a nick q:line as it won't be prefixed by #; i honestly can't see any reason not to use a q:line for both.

(0012183) aquanight (reporter) 2006-08-16 09:59	Unless you get wildcards involved. Then you get fun things like hello bans both nicks and channels. No it'd probably more like: if the mask starts with a #, it's a channel ban, and if it doesn't, it's not.

(0012184) djGrrr (reporter) 2006-08-16 10:13	yeah, i actually thought about that after i posted, hmmm, there has to be an easy way to do it, while still keeping the same tkl

(0012947) Trocotronic (reporter) 2006-12-28 12:31	Fixed in .2320