View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001919 | unreal | ircd | public | 2004-07-05 15:19 | 2015-07-23 22:32 |
| Reporter | aquanight | Assigned To | syzop | ||
| Priority | normal | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | wont fix | ||
| Summary | 0001919: Some fun CYCLE stuff... | ||||
| Description | I've noticed that using /cycle 0 does not simply cause the user to cycle all channels they are on. Instead the user simply leaves all channels, as though they issued a /join 0. In addition, "0 No such channel" appears in the Status window. I'm not sure if it is supposed to do this, but the current behavior might confuse some people (it already proved me wrong in thinking /cycle 0 just cycles all channels) as to what /cycle is supposed to do. A user using /cycle can be reasonably expected to leave and join the channel they specify, but when using 0, they simply leave all channels with a "0 No such channel" message appearing in the Status for unknown reasons. On a related note, I think CYCLE should allow a user to include message, much the same way as PART (but maybe prefix with Cycling: or something?). (I hope haven't brought up anything that's already been posted :P ) | ||||
| 3rd party modules | |||||
|
|
Hmm, well /cycle was never really designed to deal with 0, though I can certainly see that being a nice idea. But with the reason, why would you want to specify a reason? |
|
|
Mostly because you can have PART with a reason :P . Before I knew better, sometimes I had mIRC's line marker go wierd - it wouldn't update. Of course, I discovered why much later - to get it to "work" again you had to scroll up to it and then back down :P (so as I said "Before I knew better" :P ). Up 'til I discovered that, I used /cycle to fix it. However, when I rejoined people usually asked why I kept hopping, and I had to explain what was going on. If I could do /cycle #blah Channel window broke or similar... * aquanight has left #blah (Cycling: Channel window broke) * aquanight has joined #blah <SomeoneElse> Fixed? :) <aquanight> Yup. (: Basically, it'd be nice for people to be able to fill in why they're cycling the channel so that they don't have to explain themselves afterwards :P . I could probably come up with other examples, like "Fixing desynch" (such as that stupid +ov thing, or the horrible net splitops desynch (and in rejoining, I would assume ChanServ would reop or something :P ). ) Probably others too :) |
|
|
Ok, I guess I can see the point there. Actually, adding a reason would be super easy. The hard part comes into play with the /cycle 0. Simply because I need to keep a temporary list of all the channels *sigh*. Also, Syzop, I want to get your opinion on this. I think someone mentioned it before, but it still remains. Say I am in #keyed-channel which is +k. If I /cycle, I won't rejoin that channel. So since /cycle is handled pseudo-atomically, what about making it override any modes? What I mean is, since we send m_part and m_join in the same function, it can't be possible that +k was set after you parted, it must have been set while you were already in the channel, therefore, it is safe to override. Do you agree with that analysis? |
|
|
Well, here's what I can probably see: -- For /cycle 0: I would probably say use the same code as for generating the channel list as what WHOIS is using, minus the prefixes and all the checks (except buffer length of course :P ), and instead of putting a space, use a comma. Then send the channels (or each batch since there are param limits to deal with :P ) to m_part and m_join. I took a quick look at the related code in m_whois.c myself, and I can't really see why not :) . -- For /cycle on +k: I know I'm not Syzop, but here's a thought: You'll already be enumerating channels for /cycle 0 (so you may as well use it as extra validation to be sure the user is /cycle'ing channels he is actually on - otherwise he could cycle himself past +bikl :O ), so one option is during enumeration collect the keys from channels that have them set, and send them to m_join. Alternatively, flag the user as invited to the channels (which is probably what you meant by override ;) ), which allows him to cycle through +bikl (but not necessarily +OAz, but in this case the user probably shouldn't be in the channel anyway :P ) - assuming he's already in the channel :P . Since m_cycle is atomic enough, I don't think there's need to worry about /nick in the middle of the cycle. |
|
|
Well no, I didn't mean doing all that stuff, I meant, simply skip all the +bilk checks. |
|
|
Yeah. I think flagging the user as invited would sort that out, but then you don't want to allow users putting channels they aren't on into /cycle for two reasons: 1) It doesn't make sense. <-- so it should probably be done regardless ;) 2) It would allow them to bypass +bikl that would block joining normally: * Now talking in #blah * Topic is 'Some lame topic.' * Topic set by SomeOne at January 1, 1970 12:00:00 * ChanServ sets mode: +b *!*your@*.address.here.net * You were kicked from #blah by ChanServ (Requested) #blah Unable to rejoin (address is banned) -> *Server* CYCLE #blah * Rejoined channel #blah * Topic is 'Some lame topic.' * Topic set by SomeOne at January 1, 1970 12:00:00 <~SomeOne> ... how the heck did you do that? :O * SomeOne sets mode: -b+b *!*your@*.address.here.net *!*@your.address.here.net * You were kicked from #blah by SomeOne (Ban Evasion) #blah Unable to rejoin (address is banned) -> *Server* CYCLE #blah * Rejoined channel #blah * Topic is 'Some lame topic.' * Topic set by SomeOne at January 1, 1970 12:00:00 <~SomeOne> ... okay... that's it. ERROR :Closing link you[your.address.here.net] (User has been permanently banned from ThisNetwork (Wierd Ban Evasion)) ... you get the idea. Obviously, there's a security risk in allowing CYCLE to include channels that the user isn't in if we go around flagging them as invited or otherwise overriding +bikl. |
|
|
So uh... any thoughts/updates on this? :) edited on: 2004-10-13 03:05 |
|
|
Just thought id add my two cents... What if someone is +b'd on a channel, and then they issue the mass cycle? They would rejoin the channel bypassing the ban set on them (remember you can set a ban and still be inside the channel). |
|
|
Not like it'd do them any good really. They're still banned, which means no speak, and no nickchange unless they leave. Though it could create some interesting floods from the part/join thing being sent out... so I would guess just override only +ikl. Then again, it's probably safe to assume if the user hasn't been kicked out already, he's probably ok to join but... Still, the impact of what you're saying would be minimized by only allowing cycle of channels the user is on! |
|
|
i think it should only override +ikl |
|
|
Bump. still an issue? |
|
|
[20:16:43] -> Server: cycle 0 - *** 0: No such channel As i can see.. still an issue. |
|
|
Yes, still an issue. I'm thinking easiest way to do this is just have the join bypass everything. It's an atomic operation so nothing can change in between, and if someone wasn't supposed to get back in, it's a simple matter for an op to just kick. |
|
|
I think the joining via /cycle should ignore ilkROAz, but still be stopped by +b. Cycling with a reason would be nice. /cycle 0 - Sounds even worse than amsg, except one /cycle 0 can take up 5 lines(part,join,chanserv mode, bot mode, bot greet) of everyone else's screens, whereas a single amsg takes up one line of everyone else's screen. |
|
|
I don't think we should put effort into this. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-07-05 15:19 | aquanight | New Issue | |
| 2004-07-05 17:19 |
|
Note Added: 0006869 | |
| 2004-07-05 17:29 | aquanight | Note Added: 0006870 | |
| 2004-07-05 23:48 |
|
Note Added: 0006877 | |
| 2004-07-06 00:13 | aquanight | Note Added: 0006878 | |
| 2004-07-06 00:17 |
|
Note Added: 0006879 | |
| 2004-07-06 00:39 | aquanight | Note Added: 0006880 | |
| 2004-10-13 03:05 | aquanight | Note Added: 0007996 | |
| 2004-10-13 03:05 | aquanight | Note Edited: 0007996 | |
| 2004-10-23 08:19 | Plasma | Note Added: 0008084 | |
| 2004-10-23 10:39 | aquanight | Note Added: 0008085 | |
| 2004-10-23 12:27 | White_Magic | Note Added: 0008089 | |
| 2007-04-27 06:06 |
|
Note Added: 0013853 | |
| 2007-04-27 06:06 |
|
Status | new => feedback |
| 2007-04-29 12:16 | vonitsanet | Note Added: 0013924 | |
| 2007-04-29 16:45 | aquanight | Note Added: 0013929 | |
| 2007-04-29 16:45 | aquanight | Status | feedback => confirmed |
| 2007-04-30 22:21 | Shining Phoenix | Note Added: 0013958 | |
| 2015-07-23 22:32 | syzop | Note Added: 0018554 | |
| 2015-07-23 22:32 | syzop | Status | confirmed => closed |
| 2015-07-23 22:32 | syzop | Assigned To | => syzop |
| 2015-07-23 22:32 | syzop | Resolution | open => wont fix |
