Forums Feature Suggestions /server -l nickserv and disconnection

The problem (to me) is clearly an issue of Anope interacting with UnrealIRC in a latent response. Anope informs the client that they have been authenticated, and then Anope informs UnrealIRC that it should +r the user.

I informed #anope on irc.anope.org that they should perform this operation in reverse -- first setting the user +r and only then informing them that they've successfully authenticated, so that clients can react to NickServ "Password accepted" messages.

A work-around would be to add an N second delay to reacting, or add a behavior for UnrealIRCd to check for "* NickServ sets mode: +r" messages instead.

Here:

[14:39:20] <- :fiery.ca.us.SwiftIRC.net 001 Ouims :Welcome to the SwiftIRC IRC Network Ouims!Ouims@amontsouris-158-1-25-2.w92-128.abo.wanadoo.fr
[14:39:20] -> fiery.ca.us.SwiftIRC.net NICKSERV identify PASSWORD

[14:39:20] <- :fiery.ca.us.SwiftIRC.net 002 Ouims :Your host is fiery.ca.us.SwiftIRC.net, running version UnrealIRCd-4.2.2
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 003 Ouims :This server was created Sat Mar 16 2019 at 11:48:28 UTC
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 004 Ouims fiery.ca.us.SwiftIRC.net UnrealIRCd-4.2.2 iowrsxzdHtIDZRqpWGTSB lvhopsmntikraqbeIzMQNRTOVKDdGLPZSCcf
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 005 Ouims AWAYLEN=307 CASEMAPPING=ascii CHANLIMIT=#:50 CHANMODES=beIqa,kLf,l,psmntirzMQNRTOVKDdGPZSCc CHANNELLEN=32 CHANTYPES=# DEAF=d ELIST=MNUCT EXCEPTS EXTBAN=~,tmTSOcaRrnqj HCN INVEX :are supported by this server
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 005 Ouims KICKLEN=307 KNOCK MAP MAXCHANNELS=50 MAXLIST=b:100,e:100,I:100 MAXNICKLEN=30 MODES=12 NAMESX NETWORK=SwiftIRC NICKLEN=30 PREFIX=(ohv)@%+ QUITLEN=307 :are supported by this server
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 005 Ouims SAFELIST SILENCE=10 STATUSMSG=@%+ TARGMAX=DCCALLOW:,ISON:,JOIN:,KICK:4,KILL:,LIST:,NAMES:1,NOTICE:1,PART:,PRIVMSG:4,SAJOIN:,SAPART:,USERHOST:,USERIP:,WATCH:,WHOIS:1,WHOWAS:1 TOPICLEN=360 UHNAMES USERIP WALLCHOPS WATCH=128 WATCHOPTS=A :are supported by this server
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 396 Ouims Swift-4C841731.w92-128.abo.wanadoo.fr :is now your displayed host
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 251 Ouims :There are 1 users and 397 invisible on 6 servers
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 252 Ouims 56 :operator(s) online
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 254 Ouims 436 :channels formed
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 255 Ouims :I have 202 clients and 0 servers
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 265 Ouims 202 990 :Current local users 202, max 990
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 266 Ouims 398 1672 :Current global users 398, max 1672
[14:39:20] <- :fiery.ca.us.SwiftIRC.net 422 Ouims :MOTD File is missing
[14:39:20] <- :Ouims MODE Ouims :+ix
[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :This nickname is registered and protected. If it is your
[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :nick, type /msg NickServ IDENTIFY password. Otherwise,
[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :please choose a different nick.
[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :If you do not change within 20 seconds, I will change your nick.
[14:39:20] <- :Global!services@services.host NOTICE Ouims :[Logon News - Dec 18 04:35:36 2012 UTC] This is a friendly reminder that you should only enter your NickServ password through NickServ (e.g. /ns id yourpassword). Please exercise general password safety, and remember that the SwiftIRC staff will never ask you to state or confirm your password - Thanks.
[14:39:20] <- :Global!services@services.host NOTICE Ouims :[Logon News - Jun 17 21:18:07 2013 UTC] We will now perform a passive scan on your IP to check for insecure proxies. These scans are harmless and will originate from 198.50.159.105. If you do not consent to these scans please disconnect immediately.
[14:39:20] -> fiery.ca.us.SwiftIRC.net PROTOCTL NAMESX
[14:39:20] -> fiery.ca.us.SwiftIRC.net PROTOCTL UHNAMES

[14:39:20] -> fiery.ca.us.SwiftIRC.net JOIN #mircscripting,#pacman

[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :Password accepted - you are now recognized.

[14:39:21] <- :fiery.ca.us.SwiftIRC.net 477 Ouims #mircscripting :You need a registered nick to join that channel.
[14:39:21] <- :fiery.ca.us.SwiftIRC.net 477 Ouims #pacman :You need a registered nick to join that channel.

[14:39:21] <- :Ouims!Ouims@Swift-4C841731.w92-128.abo.wanadoo.fr CHGHOST Ouims simple.mIRC.user
[14:39:21] <- :fiery.ca.us.SwiftIRC.net 396 Ouims simple.mIRC.user :is now your displayed host
[14:39:21] <- :HostServ!services@services.host NOTICE Ouims :Your vhost of simple.mIRC.user is now activated.

[14:39:21] <- :NickServ MODE Ouims :+r

Thanks for the debug details. This seems to shows that even though the client has sent:


the server is still sending:


to tell the client that it needs to send the nickserv identify message.

As discussed before, this is the notice that mIRC looks for to know when to continue with the perform.

It looks like the server is not processing nickserv identify in a way that synchronizes with its own nickserv notices.

While a client could wait for the "mode +r" instead, again as discussed before, the +r mode means different things on different networks, so this is not reliable and would need to be set to a different value for different networks. In addition, some networks do not send "mode +r", they just send another notice.

As far as nickserv still sending out notices about the nickname being registered, it's been that way for a long time, and a different network, Epiknet, behaves exactly the same regarding those notices. Also, in the debug, you can see that the identify command is sent at the same second than the notice is received, so it's looks normal for nickserv to be too late to cancel the sending.


What you quoted doesn't contain a message from nickserv that appears once you're identified, so I'm not sure which notice you're talking about.

In the debug, the join message sent by mIRC is clearly sent before mIRC has seen either the +r usermode or the notice from nickserv which is in this case "[16:51:41] <- :NickServ!services@services.host NOTICE Ouims :Password accepted - you are now recognized"

I'm sorry I don't really understand your reply or how exacly is mIRC deciding to go ahead and send the join message, it seems to me that the timestamp shows the same seconds for the join and the nickserv notice that would be used by mIRC, but the join command is displayed first, indicating it was sent before receiving the nickserv's notice

[14:39:20] -> fiery.ca.us.SwiftIRC.net JOIN #mircscripting,#pacman
[14:39:20] <- :NickServ!services@services.host NOTICE Ouims :Password accepted - you are now recognized.
[14:39:21] <- :fiery.ca.us.SwiftIRC.net 477 Ouims #mircscripting :You need a registered nick to join that channel.

It is sent the moment numeric 001 is received, at the top of the debug log.


This has already been discussed. Please read the thread about how nickserv support was implemented.

If you can think of a way of implementing support for nickserv that is not dependent on the english language and that works across all networks, please let us know.

So the relevant part:

The arbitrary choice of ignoring some notices and not the others is causing it to fail, and people are being very luckly if it's currently working for them.

I do not have a magic solution, I do agree the server side is to blame.

If you absolutely want to be language-independent and don't want to use +r because some network don't support it, wouldn't it be possible to suggest something to add into IRCv3 to cater for this problem? Like sending a specific raw as you mentioned or similar.

I just noticed that swiftirc nickserv sends the notice "Password accepted - you are now recognized" whereas Freenode nickserv sends "You are now identified for nickname". So even using english to determine success will not work reliably as the wording could vary from network to network.

mIRC could delay perform by several seconds after seeing the last nickserv notice. This would resolve the issue in your particular case, unless nickserv takes too long. This will be in the next version.

I agree that if we're about to do something that cannot work reliably, then a delay is simple and best (I've been using /autojoin -d3 in perform for most of my life).

Delaying perform would add more delay for people who use /autojoin -dN there, given that it's unreliable in the first place, I don't want mIRC to add more delay.

It was said multiple times over the years in the various thread about adding nickserv support, scripts are best for handling non standard or unreliable things and it's true.

I think the best mIRC can do for now is offer a 'scripted' solution via its UI: add two editboxes in the 'edit server' dialog.

-One defaulting to 'nickserv', used to indicate the nickname of nickserv (which can be any nickname in reality, e.g. Themis on Epiknet)
-A second one representing a wildcard (or regex, via a checkbox, for completeness sake) expression that mIRC would use to match against nickserv's notices

And a new switch for /server, like server -bg "nick expression", g meaning regex.


Edit: since the nickserv method only do /nickserv, the editbox for the nickname would be only relevant for the msg method

The latest beta includes a few seconds extra delay after the last nickserv notice is received. The method is still dependent on how fast nickserv process the logon, so it is still possible that it may not always work. However, since you were seeing this issue so rarely before, this change should help.