View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003044 | unreal | ircd | public | 2006-08-30 17:48 | 2006-09-03 16:00 |
| Reporter | JasonTik | Assigned To | aquanight | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| OS | * | OS Version | * | ||
| Product Version | 3.2.5 | ||||
| Fixed in Version | 3.2.6 | ||||
| Summary | 0003044: SVSNICK Collisions | ||||
| Description | When services sends SVSNICK User1 User2 1, if User2 exists, timestamps are not obeyed, but User1 is killed. This is annoying, and imo, either services should win, or timestamps should win. Also, case changes result in a collision when they shouldnt. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
If this is to do with nick guesting causing collisions, then your best bet is to set your services to use svshold instead of creating an enforcer user, that way no collisions happen |
|
|
That is not the case. This has only to do with renaming users. No enforcer is created. |
|
|
Personally I just do an is_online($nick) check in services before I use svsnick. |
|
|
[quote]if User2 exists, timestamps are not obeyed, but User1 is killed.[/quote] You mean, User2 is killed, right? Yeah, that's intended. |
|
|
Actually, User1 is. if (find_client(parv[2], NULL)) /* Collision */ return exit_client(cptr, acptr, sptr, "Nickname collision due to Services enforced " "nickname change, your nick was overruled"); |
|
|
Hm, I see. I wouldn't be surprised if the intention was to kill User2. Maybe codemastr can shed some light on this. (Unrelated, but.. in any case, we should not 'return' with an 'exit_client()' for another user, since that will incorrectly return FLUSH_BUFFER for a client that STILL EXISTS) |
|
|
I *think* this was intended. The logic (as I remember) is as follows: Services generally changes nicknames of users for 1 reason - the nickname he/she is using is invalid. It is invalid because either a.) it is registered to someone else, b.) it's an "unallowed" nickname (qlines), c.) something else along those lines that we never considered. A key point here to remember is the IRCd is never designed for RAW commands. Unreal isn't considering at all the fact that you just want to have fun with people's nicknames. Anyway, when one of these invalid nicknames is detected, services may issue on SVSNICK to change the user's nickname to something legal (an alternative to just killing the user. Remember, the user didn't necessarily try to do something wrong, so a kill is harsh). So I logon as JasonTik, services decides to change my name to Guest12345. However, someone else is already online with the nickname Guest12345. That user has done nothing wrong. He/she chose a 100% legal nickname to use. Or for that matter, may have been assigned that nickname by a previous SVSNICK. So, why should he be killed in this collision? *I* the person who logged on as JasonTik am the one who violated the rules. Hence, I'm the one who gets punished, by being killed. The "loser" in the collision is, in my opinion, the guy who is currently trying to take someone elses nickname (me). The alternative, of course, would be to have services continually do an while(nickExists(guestNick)) guestNick = newGuestNick();. That too solves such issues. But I don't see this as wrong on our part. I think the logic is correct (though I agree with you the case changing may be an issue). |
|
|
Case-change and returning FLUSH_BUFFER fixed in .2262. I also noticed (and fixed) that QUIT wasn't being sent back toward services on a collision (which would no doubt cause massive desynchs). |
|
|
Services should have enough intelligence to not reuse a Guest nick when SVSNICKing a user. If services did SVSNICK a user to an existing user intentionally it was because it was doing some sort of auto-NICK-on-IDENTIFY thing. I identify to Jason, i get SVSNICKed to Jason. My clone/ghost/etc is gone. I have seen services that do this. I see case changes have been fixed, but what has been decided on the Timestamp/User1/User2 thing? |
|
|
I have been debating writing a GIDENTIFY which would ghost, and SVSNICK. but it would specifically KILL or SVSKILL first |
|
|
Fix for case-change thingy is in 3.2* and 3.3*. As for 'who to kill', codemastr's reasoning sounds logical for the purpose of SVSKILL that he means. If there should be another SVSNICK which kills the 'target client', I suppose one could suggest a SVS2NICK or something. EDIT: NICK, not KILL... tnx aquanight ;p |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-08-30 17:48 | JasonTik | New Issue | |
| 2006-08-31 08:43 | djGrrr | Note Added: 0012268 | |
| 2006-08-31 13:00 | JasonTik | Note Added: 0012269 | |
| 2006-08-31 23:22 | tabrisnet | Note Added: 0012271 | |
| 2006-09-01 04:58 | syzop | Note Added: 0012272 | |
| 2006-09-01 13:36 | aquanight | Note Added: 0012282 | |
| 2006-09-01 13:39 | aquanight | Note Edited: 0012282 | |
| 2006-09-01 17:46 | syzop | Note Added: 0012284 | |
| 2006-09-01 17:46 | syzop | Note Edited: 0012284 | |
| 2006-09-02 12:34 |
|
Note Added: 0012292 | |
| 2006-09-03 14:01 | aquanight | Status | new => assigned |
| 2006-09-03 14:01 | aquanight | Assigned To | => aquanight |
| 2006-09-03 14:51 | aquanight | Note Added: 0012299 | |
| 2006-09-03 15:08 | JasonTik | Note Added: 0012300 | |
| 2006-09-03 15:11 | tabrisnet | Note Added: 0012301 | |
| 2006-09-03 16:00 | syzop | Status | assigned => resolved |
| 2006-09-03 16:00 | syzop | Fixed in Version | => 3.2.6 |
| 2006-09-03 16:00 | syzop | Resolution | open => fixed |
| 2006-09-03 16:00 | syzop | Note Added: 0012302 | |
| 2006-09-03 16:03 | syzop | Note Edited: 0012302 |
