View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002074 | unreal | ircd | public | 2004-09-16 01:34 | 2005-02-26 18:57 |
| Reporter | Zell | Assigned To | syzop | ||
| Priority | normal | Severity | trivial | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | all | OS | all | OS Version | all |
| Product Version | 3.2.1 | ||||
| Fixed in Version | 3.2.3 | ||||
| Summary | 0002074: illegal character in nickname bug | ||||
| Description | Inputting a ~ at the start of your nickname causes the "illegal characters" message to be sent incorrectly (doesnt show you what the invalid nick was) Inputting a ~ in the middle of the nick causes the server to negate input past the ~ mark (Example: /nick Ze~ll changes your nick to Ze). This is a bug since the illegal character does not fault the entire nick. Im thinking this bug is related to how the ~ is used in the code... | ||||
| Additional Information | Testing with a normal illegal character: NICK :&Zell 432 Zell &Zell :Erroneous Nickname: Illegal characters Testing with the ~ character: NICK :~Zell 432 Zell :Erroneous Nickname: Illegal characters Testing with the ~ in the middle: NICK :Ze~ll <-:Zell![censored]@[censored] NICK :Ze | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
The theory is: how many characters can we accept from the given nickname starting from the first character? If 0, deny the nick, otherwise truncate the nickname. I don't think that should be a bug. |
|
|
@your second thing with ~ in middle of nick As angrywolf explained, this is how we made things work indeed... with that ~ gets threated the same as with any other illegal character. Only when it's the first character that is illegal it gets completely denied since we can't do anything with it. I'm personally not too keen on always denying the whole NICK in case of an invalid character somewhere (except 1st pos.), I noticed some servers doing this but I find it kinda inconsisitent.. for example, other 'changes' are still silently done, like '/nick aaaaaaaaaaaaaaaaabbbbbbbbbbbbcccccccc' still gets you nick 'aaaaaaaaaaaa' etc. I think our current behavior is just fine. |
|
|
Agreed. Yet do you notice how the Invalid nickname is not reported back to you if the '~' is the first character? |
|
|
I think he is referring to: NICK :&Zell 432 Zell &Zell :Erroneous Nickname: Illegal characters Testing with the ~ character: NICK :~Zell 432 Zell :Erroneous Nickname: Illegal characters Testing with the ~ in the middle: In the first case, it echoed back &Zell, but it does not echo back ~Zell which does seem to be a bug. |
|
|
don't worry, I did notice... I was specificly talking about the second thing. The 1st issue is obvious of course, hence.. I didn't even bother to comment on it :p |
|
|
This is interesting. Apparently, ~ is handled separately from the other checks, and I can't understand why. Everything else is handled by do_nick_name. But ~ is handled before all that. We find the first ~ and set it to NULL. I can't see any reason for this. It's really strange because it seems other IRCds do it the same way! I think the solution is just to move the ~ check to do_nick_name just like everything else. Unless anyone sees any reason why it is the way it is? NOTE: The way it is, would allow SVSNICK to set a nick with a ~ in it which is IMHO pretty bad. |
|
|
I know nothing, but would that have anything to do with the whole "no ident, prefixing with '~'" thing... |
|
|
(w00t: no idea, but it's old [there are a few private bugnotes which you can't see here]) I've been working on 0002070, I'll also fix this ~ issue when I'm at it. |
|
|
I got an access denied on 002070 - just so you know :p |
|
|
yes, it's marked private so we don't get any w00t-replies *grin* ;). |
|
|
Am I really that bad? :/ |
|
|
nah ;). [anyway, I'm off to bed :p] |
|
|
Fixed in .191: - Nicks with ~ are now also not cutoff anymore but rejected like any other illegal char (0002074). |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2004-09-16 01:34 | Zell | New Issue | |
| 2004-09-16 04:44 | AngryWolf | Note Added: 0007662 | |
| 2004-09-16 18:38 | syzop | Note Added: 0007663 | |
| 2004-09-16 20:45 | Zell | Note Added: 0007664 | |
| 2004-09-16 21:00 |
|
Note Added: 0007665 | |
| 2004-09-16 21:29 | syzop | Note Added: 0007667 | |
| 2004-09-18 22:58 |
|
Note Added: 0007715 | |
| 2004-09-21 01:25 | w00t | Note Added: 0007746 | |
| 2004-09-21 02:12 | syzop | Note Added: 0007747 | |
| 2004-09-21 02:17 | w00t | Note Added: 0007748 | |
| 2004-09-21 02:22 | syzop | Note Added: 0007749 | |
| 2004-09-21 02:25 | w00t | Note Added: 0007750 | |
| 2004-09-21 02:31 | syzop | Note Added: 0007751 | |
| 2005-02-26 18:57 | syzop | Status | new => resolved |
| 2005-02-26 18:57 | syzop | Fixed in Version | => 3.2.3 |
| 2005-02-26 18:57 | syzop | Resolution | open => fixed |
| 2005-02-26 18:57 | syzop | Assigned To | => syzop |
| 2005-02-26 18:57 | syzop | Note Added: 0009326 |
