View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002154 | unreal | ircd | public | 2004-11-02 15:15 | 2007-12-30 11:39 |
| Reporter | aquanight | Assigned To | |||
| Priority | normal | Severity | trivial | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | X86 | OS | Windows | OS Version | XP Pro SP2 |
| Product Version | 3.2.2 | ||||
| Summary | 0002154: PART vs SAPART? | ||||
| Description | Stskeeps brought up an interesting issue concerning the SAPART reason stuff in #unreal-support... <@JK> aquanight, scary part msg <+haltdef> ? <@JK> aquanight, "(SAPart: boo)" :P <+aquanight> heh <+aquanight> what's so scary about it? :P <+aquanight> especially since 3.2.2 will do that for a real SAPART :p <@JK> :P -- Here it is :P -- < < < <+aquanight> Stskeeps: ? <@JK> lol <+aquanight> the SAPart: but is constant <+aquanight> bit* <+aquanight> but hm < <+aquanight> oh yea, well regular /part... < <+aquanight> yah <+aquanight> I know <+aquanight> hm <@JK> THere should be way by which to distinguish server-added messages from user-added ones :-) <+aquanight> well there is an easy way to do that <+aquanight> change /sapart from a :victim PART #channel :SAPart: message to :server.name KICK #channel victim :message <@JK> Having no distinction makes for paranoia and intability :/ <+aquanight> there aren't any server generated kicks except for +f [t] <@JK> Hey I'm all in favour of that, but I imagine some would oppose that <@JK> not to mention all the people coming here to whine :( <+aquanight> only problem is the difference in how clients interpret KICK as opposed to PART <+aquanight> for example, a client might not autorejoin if it receives an unexpected PART - it just closes the channel window no questions asked <@JK> They should treat it nearly identical really <+aquanight> KICK on the other hand... So yeah. I think it's probably pretty trivial to fix. Just make /part reject the reason if it starts with SAPart: and isn't coming from m_sapart :P . | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
| child of | 0003111 | closed | 3.2.7 Release |
|
|
First, what's the big deal, I don't really see much of an issue? Second, I think the old alternative was worse - opers being able to fake parts from users Third, no this isn't something I overlooked when adding the "SAPart:" prefix, it was simply something I didn't think was a big deal. |
|
|
Indeed, really it's the same thing as having set { prefix-quit "no"; }; ... SomeOp: /kill SomeOne Bye. * SomeOne ([email protected]) Quit ([server.name] Local kill by SomeOp (Bye) SomeOne: /quit [server.name] Local kill by SomeOp (Bye) * SomeOne ([email protected]) Quit ([server.name] Local kill by SomeOp (Bye) I'd suggest a prefix-part, but that's overkill when there's only one server-generated part (and not even 100% server-generated at that) really... if people abuse that too much then it's not hard for the admin to disable part reasons :P . |
|
|
If you're really that paranoid, you can still use the Spamfilter to block reasons starting with SAPart... |
|
|
*bump* |
|
|
Clients do handle kick different from part! Most clients will leave the window open when kicked, so you can read the last lines before you got kicked. But parting is (mostly) done by yourself, so the window gets closed, first parting, and closing the window after that wouldn't make sense. |
|
|
dropped. too much cpu for something stupid (a simple string comparison will not suffice). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-11-02 15:15 | aquanight | New Issue | |
| 2004-11-02 17:13 |
|
Note Added: 0008223 | |
| 2004-11-02 17:23 | aquanight | Note Added: 0008225 | |
| 2004-11-03 05:41 | Dukat | Note Added: 0008229 | |
| 2006-11-12 15:06 | syzop | Relationship added | child of 0003111 |
| 2007-04-19 07:23 | vonitsanet | Note Added: 0013602 | |
| 2007-04-19 07:32 |
|
Status | new => acknowledged |
| 2007-09-06 10:10 | syzop | Relationship added | child of 0003454 |
| 2007-12-24 13:53 | Quis | Note Added: 0014930 | |
| 2007-12-30 11:35 | syzop | Relationship deleted | child of 0003454 |
| 2007-12-30 11:36 | syzop | Note Added: 0014948 | |
| 2007-12-30 11:39 | syzop | QA | => Not touched yet by developer |
| 2007-12-30 11:39 | syzop | U4: Need for upstream patch | => No need for upstream InspIRCd patch |
| 2007-12-30 11:39 | syzop | Status | acknowledged => closed |
| 2007-12-30 11:39 | syzop | Resolution | open => no change required |
