View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003012 | unreal | ircd | public | 2006-08-01 11:56 | 2013-05-07 07:01 |
| Reporter | Jase | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| OS | FreeBSD | OS Version | 4.6 | ||
| Product Version | 3.2.6 | ||||
| Target Version | 3.3-alpha0 | Fixed in Version | 3.4-alpha1 | ||
| Summary | 0003012: Ability to sqline channels. | ||||
| Description | I would like to suggest the ability to support sqlining of channels. Recently I tried on my network running Anope Services, and when I tried to issue the operserv sqline command and apply it to a channel, I was told that applying a sqline to a channel was not supported by Unreal. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| has duplicate | 0000935 | resolved | Trocotronic | SQLINE command but for channel banning |
|
|
What's the point of this? |
|
|
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. |
|
|
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) |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
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 |
|
|
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) |
|
|
(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:.) |
|
|
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. |
|
|
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 |
|
|
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) |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
Fixed in .2320 |
|
|
http://hg.unrealircd.org/hg/unreal/rev/78cb3fbc7841 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-08-01 11:56 | Jase | New Issue | |
| 2006-08-02 22:58 |
|
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 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 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-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 | |
| 2010-07-02 10:22 | syzop | Relationship added | parent of 0003915 |
| 2011-07-19 13:58 | syzop | Assigned To | Trocotronic => |
| 2011-07-19 13:58 | syzop | Status | resolved => needs re porting |
| 2011-07-19 17:11 | syzop | Target Version | => 3.3-alpha0 |
| 2012-10-15 21:27 | syzop | Relationship deleted | parent of 0003915 |
| 2013-05-07 07:00 |
|
Note Added: 0017522 | |
| 2013-05-07 07:00 |
|
Status | needs re porting => resolved |
| 2013-05-07 07:00 |
|
Fixed in Version | 3.3-alpha0 => 3.4-alpha1 |
| 2013-05-07 07:00 |
|
Assigned To | => nenolod |
