View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003733 | unreal | ircd | public | 2008-10-01 07:37 | 2015-08-08 16:31 |
| Reporter | Jobe | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.7 | ||||
| Summary | 0003733: SVS2MODE -r+d Not showing -r to user | ||||
| Description | OK, simple bug really, when services issues an SVS2MODE -r+d <stamp> for a user, the -r user mode change is NOT passed back to the user where the documentation says it should be. Thus SVS2MODE -r+d <stamp> acts EXACTLY the same as SVSMODE -r+d <stamp>. | ||||
| 3rd party modules | |||||
|
|
works here. services server: SVS2MODE Ein +r SVS2MODE Ein -r SVS2MODE Ein +r SVS2MODE Ein -r+d 999 on client side: [17:48:36] * services.test.net sets mode: +r [17:48:42] * services.test.net sets mode: -r [17:48:45] * services.test.net sets mode: +r [17:48:49] * services.test.net sets mode: -r |
|
|
Well below you can see an example of the situation. Client side debug log: -> irc.foonet.com IDENTIFY password <- :services.foonet.com MODE jobe :+r <- :[email protected] NOTICE jobe :Password accepted - you are now recognized. -> irc.foonet.com NICK :Eboj <- :irc.foonet.com NOTICE jobe :*** Notice -- jobe ([email protected]) has changed his/her nickname to Eboj <- :[email protected] NICK :Eboj -> irc.foonet.com NICK :Jobe <- :irc.foonet.com NOTICE Eboj :*** Notice -- Eboj ([email protected]) has changed his/her nickname to Jobe <- :[email protected] NICK :Jobe <- :[email protected] NOTICE Jobe :This nickname is registered and protected. If it is your <- :[email protected] NOTICE Jobe :nick, type /msg NickServ IDENTIFY password. Otherwise, <- :[email protected] NOTICE Jobe :please choose a different nick. -> irc.foonet.com IDENTIFY password <- :services.foonet.com MODE Jobe :+r <- :[email protected] NOTICE Jobe :Password accepted - you are now recognized. Services Side debug log: [Dec 23 18:45:26.836135 2008] debug: Received: :jobe PRIVMSG [email protected] :IDENTIFY password [Dec 23 18:45:26.836386 2008] debug: Sent: :services.foonet.com SVS2MODE jobe +rd 1230057922 [Dec 23 18:45:26.836441 2008] debug: Changing mode for jobe to +rd [Dec 23 18:45:26.836491 2008] debug: Emitting event "nick_id" (1 args) [Dec 23 18:45:26.836536 2008] NickServ: [email protected] identified for nick jobe [Dec 23 18:45:26.836602 2008] debug: Sent: :NickServ NOTICE jobe :Password accepted - you are now recognized. [Dec 23 18:45:35.851356 2008] debug: Received: :jobe NICK Eboj 1230057934 [Dec 23 18:45:35.851448 2008] debug: jobe changes nick to Eboj [Dec 23 18:45:35.851498 2008] LOGUSERS: jobe ([email protected] => netadmin.foonet.com) (Jobe) changed nick to Eboj (irc.foonet.com). [Dec 23 18:45:35.851552 2008] debug: Emitting event "change_nick" (1 args) [Dec 23 18:45:35.851675 2008] debug: Sent: :services.foonet.com SVS2MODE Eboj -r+d 1 [Dec 23 18:45:35.851731 2008] debug: Changing mode for Eboj to -r+d [Dec 23 18:45:40.469519 2008] debug: Received: :Eboj NICK Jobe 1230057938 [Dec 23 18:45:40.469607 2008] debug: Eboj changes nick to Jobe [Dec 23 18:45:40.469651 2008] LOGUSERS: Eboj ([email protected] => netadmin.foonet.com) (Jobe) changed nick to Jobe (irc.foonet.com). [Dec 23 18:45:40.469700 2008] debug: Emitting event "change_nick" (1 args) [Dec 23 18:45:40.469789 2008] debug: Sent: :services.foonet.com SVS2MODE Jobe -r+d 1 [Dec 23 18:45:40.469845 2008] debug: Changing mode for Jobe to -r+d [Dec 23 18:45:40.469926 2008] debug: Sent: :NickServ NOTICE Jobe :This nickname is registered and protected. If it is your [Dec 23 18:45:40.469982 2008] debug: Sent: :NickServ NOTICE Jobe :nick, type /msg NickServ IDENTIFY password. Otherwise, [Dec 23 18:45:40.470038 2008] debug: Sent: :NickServ NOTICE Jobe :please choose a different nick. [Dec 23 18:45:43.411782 2008] debug: Received: :Jobe PRIVMSG [email protected] :IDENTIFY password [Dec 23 18:45:43.411932 2008] debug: Sent: :services.foonet.com SVS2MODE Jobe +rd 1230057938 [Dec 23 18:45:43.411985 2008] debug: Changing mode for Jobe to +rd [Dec 23 18:45:43.412033 2008] debug: Emitting event "nick_id" (1 args) [Dec 23 18:45:43.412078 2008] NickServ: [email protected] identified for nick Jobe [Dec 23 18:45:43.412145 2008] debug: Sent: :NickServ NOTICE Jobe :Password accepted - you are now recognized. Now you can clearly see that the client is NOT receiving a MODE -r, but Services IS sending an SVS2MODE Eboj -r+d 1 Now at this point the question has to be asked, does UnrealIRCd automatically remove user mode +r on nick change too? If so, why is the client not told about it? |
|
|
If the user is -r, then you won't see a -r, that's as expected. Yes, with a nickchange you get -r'd automatically, anything else is insecure as there would be a window where a user would appear to registered as someone else. Why isn't the user told about it? I don't know the full reasoning behind that, I know people tend to disagree about all that kind of stuff... hence SVSMODE and SVS2MODE, but am not planning to change it. You should understand though that it could be considered annoying or 'odd' if a user has registered nick A linked with A[away] and A[brb]. When he then changes from A to A[away] you would see a -r followed by a +r one or a few seconds later, same if he changes back... That could be one reason. If you'd like to see notification of -r on nickchange, feel free to write a patch (new config setting, default = current behavior). I won't include it in 3.2.8 though, as I'm closing that code/merge/whateveritscalled window as we speak :P. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-10-01 07:37 | Jobe | New Issue | |
| 2008-12-23 16:50 | syzop | Note Added: 0015515 | |
| 2008-12-23 18:51 | Jobe | Note Added: 0015518 | |
| 2008-12-23 18:53 | Jobe | Note Edited: 0015518 | |
| 2008-12-23 20:05 | syzop | Note Added: 0015521 | |
| 2015-08-08 16:31 | syzop | Status | new => closed |
| 2015-08-08 16:31 | syzop | Assigned To | => syzop |
| 2015-08-08 16:31 | syzop | Resolution | open => no change required |
