mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Where you have a server definition that includes a Login method and channel favourites that have Enable Join on Connect ticked, the Join on Connect happens before the authentication has taken place. If that channel has mode +r set then the join is disallowed and you get a 477 message "Cannot join channel (+r) - you need to be logged into your NickServ account".

The authentication being complete may be a little difficult to detect and may vary by ircd type. Here is what I get on Libera.Chat:

Code
:NickServ!NickServ@services.libera.chat NOTICE mynick :You are now identified for mynick.
:NickServ!NickServ@services.libera.chat NOTICE mynick :Last login from: myaddress on Jan 29 10:13:43 2022 +0000.
@account=myaccount :myaddress ACCOUNT myaccount


It would be great to have an enhancements that when you connect to a server with a Login method set, then either:

A. doing a Join on Connect for favourite channels should be delayed until the authentication has been confirmed; or
B. autojoins are done immediately upon connection as now but if you do the autojoin and get a 477 then this is supressed and the autojoin is retried when the authentication is complete.

Joined: Dec 2002
Posts: 5,420
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,420
Thanks for your bug report. I just tested this on Libera.Chat and was unable to reproduce this issue.

I set Libera.Chat to login using nickserv. When I connect, I can see the nickserv login being sent the moment the Welcome message is received from the server. mIRC waits for a reply from nickserv, confirming that I have been identified, before the join on connect is triggered and the channel is joined.

I recall we looked into this issue here some time ago and that the above behaviour was implemented at the time.

Can you provide a step by step method that reproduces this issue for you?

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
LOL - the previous request was also by me, but I had forgotten all about it!!

It is getting the following message from Nickserv which does not contain the required strings to continue waiting so it tries to join the channel:
Code
:NickServ!NickServ@services.libera.chat NOTICE Sophist-UK :You have 10 seconds to identify to your nickname before it is changed.

If you are willing to put the effort in I would recommend the following:

1. Remove the code you put in last time
2. Add code that reacts to a 477 message by: A) hiding the message; B) waiting (say) 5s and retrying the join; C) repeat the retry up to 12 times taking c. 1m and then show the final 477 message to the user and stop trying.

Joined: Dec 2002
Posts: 5,420
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,420
I have not been able to reproduce this issue so far. Please use the /debug command and paste the server log here so that we can see the sequence of server messages when you connect to a server, including the 001 welcome message, nickserv logon message, and so on.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Code
-> molybdenum.libera.chat QUIT :
-> irc.libera.chat CAP LS 302
-> irc.libera.chat NICK MyNick
-> irc.libera.chat USER MyUser 0 * :MyUser
<- :strontium.libera.chat NOTICE * :*** Checking Ident
<- :strontium.libera.chat NOTICE * :*** Looking up your hostname...
<- :strontium.libera.chat NOTICE * :*** Found your hostname: 128.128.158.5.rev.myisp.pt
<- :strontium.libera.chat NOTICE * :*** Got Ident response
<- :strontium.libera.chat CAP * LS :account-notify away-notify chghost extended-join multi-prefix sasl=PLAIN,ECDSA-NIST256P-CHALLENGE,EXTERNAL tls account-tag cap-notify echo-message solanum.chat/identify-msg solanum.chat/oper solanum.chat/realhost
-> irc.libera.chat CAP REQ :account-notify
-> irc.libera.chat CAP REQ :away-notify
-> irc.libera.chat CAP REQ :chghost
-> irc.libera.chat CAP REQ :extended-join
-> irc.libera.chat CAP REQ :multi-prefix
-> irc.libera.chat CAP REQ :account-tag
<- :strontium.libera.chat CAP MyNick ACK :account-notify
<- :strontium.libera.chat CAP MyNick ACK :away-notify
<- :strontium.libera.chat CAP MyNick ACK :chghost
<- :strontium.libera.chat CAP MyNick ACK :extended-join
<- :strontium.libera.chat CAP MyNick ACK :multi-prefix
<- :strontium.libera.chat CAP MyNick ACK :account-tag
-> irc.libera.chat CAP LIST
-> irc.libera.chat CAP END
<- :strontium.libera.chat CAP MyNick LIST :account-notify away-notify chghost extended-join multi-prefix account-tag cap-notify
<- :strontium.libera.chat 001 MyNick :Welcome to the Libera.Chat Internet Relay Chat Network MyNick
-> strontium.libera.chat PRIVMSG nickserv :identify MyPassword
-> strontium.libera.chat USERHOST MyNick
<- :strontium.libera.chat 002 MyNick :Your host is strontium.libera.chat[204.225.96.123/6697], running version solanum-1.0-dev
<- :strontium.libera.chat 003 MyNick :This server was created Sat Oct 30 2021 at 17:56:22 UTC
<- :strontium.libera.chat 004 MyNick strontium.libera.chat solanum-1.0-dev DGQRSZaghilopsuwz CFILMPQSTbcefgijklmnopqrstuvz bkloveqjfI
<- :strontium.libera.chat 005 MyNick MONITOR=100 CALLERID=g WHOX FNC ETRACE KNOCK SAFELIST ELIST=CMNTU CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQSTcgimnprstuz :are supported by this server
<- :strontium.libera.chat 005 MyNick CHANLIMIT=#:250 PREFIX=(ov)@+ MAXLIST=bqeI:100 MODES=4 NETWORK=Libera.Chat STATUSMSG=@+ CASEMAPPING=rfc1459 NICKLEN=16 MAXNICKLEN=16 CHANNELLEN=50 TOPICLEN=390 DEAF=D :are supported by this server
<- :strontium.libera.chat 005 MyNick TARGMAX=NAMES:1,LIST:1,KICK:1,WHOIS:1,PRIVMSG:4,NOTICE:4,ACCEPT:,MONITOR: EXTBAN=$,ajrxz :are supported by this server
<- :strontium.libera.chat 251 MyNick :There are 67 users and 48669 invisible on 27 servers
<- :strontium.libera.chat 252 MyNick 40 :IRC Operators online
<- :strontium.libera.chat 253 MyNick 9 :unknown connection(s)
<- :strontium.libera.chat 254 MyNick 21151 :channels formed
<- :strontium.libera.chat 255 MyNick :I have 3115 clients and 1 servers
<- :strontium.libera.chat 265 MyNick 3115 4559 :Current local users 3115, max 4559
<- :strontium.libera.chat 266 MyNick 48736 50890 :Current global users 48736, max 50890
<- :strontium.libera.chat 250 MyNick :Highest connection count: 4560 (4559 clients) (408651 connections received)
<- :strontium.libera.chat 375 MyNick :- strontium.libera.chat Message of the Day - 
<- :strontium.libera.chat 372 MyNick :- Welcome to Libera Chat, the IRC network for
<- :strontium.libera.chat 372 MyNick :- free & open-source software and peer directed projects.
<- :strontium.libera.chat 372 MyNick :-  
<- :strontium.libera.chat 372 MyNick :- Use of Libera Chat is governed by our network policies.
<- :strontium.libera.chat 372 MyNick :-  
<- :strontium.libera.chat 372 MyNick :- To reduce network abuses we perform open proxy checks
<- :strontium.libera.chat 372 MyNick :- on hosts at connection time.
<- :strontium.libera.chat 372 MyNick :-  
<- :strontium.libera.chat 372 MyNick :- Please visit us in #libera for questions and support.
<- :strontium.libera.chat 372 MyNick :-  
<- :strontium.libera.chat 372 MyNick :- Website and documentation:  https://libera.chat
<- :strontium.libera.chat 372 MyNick :- Webchat:                    https://web.libera.chat
<- :strontium.libera.chat 372 MyNick :- Network policies:           https://libera.chat/policies
<- :strontium.libera.chat 372 MyNick :- Email:                      support@libera.chat
<- :strontium.libera.chat 376 MyNick :End of /MOTD command.
<- :MyNick MODE MyNick :+Ziw
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :This nickname is registered. Please choose a different nickname, or identify via /msg NickServ IDENTIFY MyNick <password>
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :You have 10 seconds to identify to your nickname before it is changed.
-> strontium.libera.chat MONITOR C
-> strontium.libera.chat MONITOR + MyFriend
-> strontium.libera.chat MONITOR S
-> strontium.libera.chat MONITOR L
-> strontium.libera.chat JOIN #metabrainz,#mircscripting
<- :strontium.libera.chat 302 MyNick :MyNick=+MyNick@5.158.59.255 
<- :strontium.libera.chat 731 MyNick :MyFriend
<- :strontium.libera.chat 731 MyNick :MyFriend
<- :strontium.libera.chat 732 MyNick :MyFriend
<- :strontium.libera.chat 733 MyNick :End of MONITOR list
<- :MyNick!MyNick@128.128.158.5.rev.myisp.pt JOIN #mircscripting * :MyUser
-> strontium.libera.chat MODE #mircscripting
<- :strontium.libera.chat 332 MyNick #mircscripting :Welcome to #mIRCScripting for mIRC help | Guide: http://en.wikichip.org/wiki/mirc | Pastebin: https://mypastebin.com | 7.67: http://mirc.com/get.html | Ask on the channel and wait, no query! | https://mircscripts.net
<- :strontium.libera.chat 333 MyNick #mircscripting Ouims!~Ouims@2a01cb06a010464779968ba93d03432c.ipv6.abo.wanadoo.fr 1633202599
<- :strontium.libera.chat 353 MyNick = #mircscripting :MyNick Kvikk NiKaN @Ouims KindOne
<- :strontium.libera.chat 366 MyNick #mircscripting :End of /NAMES list.
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :You are now identified for MyNick.
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :Last login from: MyNick@128.128.158.5.rev.myisp.pt on Jan 30 09:29:18 2022 +0000.
<- @account=MyNick :MyNick!MyNick@128.128.158.5.rev.myisp.pt ACCOUNT MyNick
<- :strontium.libera.chat 396 MyNick user/mynick :is now your hidden host (set by services.)
<- :ChanServ!ChanServ@services.libera.chat MODE #mircscripting +v MyNick
<- :strontium.libera.chat 324 MyNick #mircscripting +nt
<- :strontium.libera.chat 329 MyNick #mircscripting 1621885314


Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
As you can see mIRC receives two messages from Nickserv, the first of which does contain the phrases looked for by mIRC to avoid triggering the autojoin (as described in the post you referred to), but the second of which doesn't, and so the autojoin is triggered early.
```
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :This nickname is registered. Please choose a different nickname, or identify via /msg NickServ IDENTIFY MyNick <password>
<- :NickServ!NickServ@services.libera.chat NOTICE MyNick :You have 10 seconds to identify to your nickname before it is changed.
...
-> strontium.libera.chat JOIN #metabrainz,#mircscripting
```

Joined: Dec 2002
Posts: 5,420
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,420
Okay, this is the same issue that we discussed before: every IRC network is using a different method/wording/format, that can change over time, for letting the client know that it has logged on with a registered nickname. This means that there is no way for a client to determine when this has actually happened, and this affects all subsequent actions, such as joining channels, that depend on the user being logged on to the network.

In the current implementation, mIRC waits at most 60 seconds for a notice from "nickserv" before continuing the logon process. mIRC assumes that the first "nickserv" notice it sees is a notification that the nickname logon process has completed. It doesn't check the language/wording/format of the notice because, as mentioned above, every network uses a different one, and it changes over time.

However, because some networks send the "This nickname is registered" notice, even if a client has already sent the nickserv logon (mIRC sends it right after numeric 001), mIRC ignores the first "nickserv" notice from networks if it contains "/msg" or "/nickserv", since that is assumed to be reminder about needing to log on.

For your current issue, you are also seeing a "You have 10 seconds to identify" notice in addition to the first notice. mIRC would have to ignore this notice but there is no simple way to do this without checking for that exact wording, which could change eg. "30 seconds" and mIRC would need to store and update this for every IRC network that uses a different phrase, different language, and so on.

This type of event really needs to be a numeric.

That said, how are you reproducing this? I have tried connecting to Libera.Chat many times with nickserv and have not seen this second notice.

As for your suggested solution: if I set my favorites dialog to join ten channels on connect, your suggestion would require mIRC to send, in a worst case scenario, 120 channel joins in the space of one minute, receiving 120 numeric 477 replies, etc. Even if you were only joining one channel, I would really not want to implement something like this because the client would essentially be ignoring a server error/warning and repeatedly trying to circumvent it.

Have you tried connecting with SASL? That resolves the issues with nickserv logons and autojoins as far as I can tell.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted by Khaled
Okay, this is the same issue that we discussed before: every IRC network is using a different method/wording/format, that can change over time, for letting the client know that it has logged on with a registered nickname. This means that there is no way for a client to determine when this has actually happened, and this affects all subsequent actions, such as joining channels, that depend on the user being logged on to the network.

In the current implementation, mIRC waits at most 60 seconds for a notice from "nickserv" before continuing the logon process. mIRC assumes that the first "nickserv" notice it sees is a notification that the nickname logon process has completed. It doesn't check the language/wording/format of the notice because, as mentioned above, every network uses a different one, and it changes over time.


Yes - I fully understand just how difficult it is to handle this in a way that will work on all servers without a structured standard on how Nickservs report that you have authenticated.

Originally Posted by Khaled
...

For your current issue, you are also seeing a "You have 10 seconds to identify" notice in addition to the first notice. mIRC would have to ignore this notice but there is no simple way to do this without checking for that exact wording, which could change eg. "30 seconds" and mIRC would need to store and update this for every IRC network that uses a different phrase, different language, and so on.

This type of event really needs to be a numeric.

That said, how are you reproducing this? I have tried connecting to Libera.Chat many times with nickserv and have not seen this second notice.


It is a Nickserv setting - or possibly two, one to limit login time and another to reduce it from 30s to 10s.

Originally Posted by Khaled
As for your suggested solution: if I set my favorites dialog to join ten channels on connect, your suggestion would require mIRC to send, in a worst case scenario, 120 channel joins in the space of one minute, receiving 120 numeric 477 replies, etc. Even if you were only joining one channel, I would really not want to implement something like this because the client would essentially be ignoring a server error/warning and repeatedly trying to circumvent it.


Hmmm... I do get what you are saying here - this needs to be scalable. But here are a few suggestions to mitigate this...

a. You could collect the channels sending a 477 message into a list and only retry only one of them (perhaps in turn) until you get a trigger (see c.) which indicates that the user has been authenticated.
b. It is not perfect for the same anarchic reasons as above, but you could try to recognise the Nickserv "You are now identified" message as a trigger for knowing the user has been authenticated. There are probably a whole bunch of message types which would indicate a successful authentication - in the above list we have 2 Nickserv messages, an @account message, the 396 message, and of course a successful join to a previously 477 channel would also indicate the same.
c. If the primary strategy is to wait (as a user would) for an authentication trigger to happen before retrying the join, then a timer based strategy would be a backup and could have a longer delay and possibly a delay that increases each time (5s, 10s, 15s, 15s) until after all these attempts have not resulted in a successful join, the 60s timeout happens as currently and you do a final attempt to rejoin and stop handing 477s and show them, to the user.

So in your example, of 10 channels requiring you to be authenticated and no Nickserv trigger, and assuming that the authentication never happens, instead of 130 477s (12 gaps of 5s means 13 attempts) you would get only 24 (10 from initial attempt to join, 4 for the timed single retries, and then a final 10 at the end of 60s. This feels to me like a reasonable compromise and seems to mimic what a real user would do if they couldn't see whether they were authenticated or not).

Originally Posted by Khaled
Have you tried connecting with SASL? That resolves the issues with nickserv logons and autojoins as far as I can tell.


No. I could try it for this server and see if that is a workaround.

Joined: Jul 2014
Posts: 316
Pan-dimensional mouse
Offline
Pan-dimensional mouse
Joined: Jul 2014
Posts: 316
I'll leave here a suggestion that can solve the problem on all networks, however it's up to Khaled to make decisions.

In the Favorites Manager dialog, two options could be added.

1st - Join only after identification of the nickname
2nd - Add a personalization of a timer that mIRC would have to join the channels, so the user could set a time of 10, 20, 30secs after the connection.

I don't know if this suggestion will be easier for Khaled to solve this problem, because as he says and well this situation changes depending on the network and so the best thing is to create something that works well on all networks.


TECO
irc.PTirc.org (Co-Admin)
Joined: Dec 2002
Posts: 5,420
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,420
Quote
Hmmm... I do get what you are saying here - this needs to be scalable. But here are a few suggestions to mitigate this...

As much as I would love to implement a state-based, multi-command-numeric-event-dependent, time-delayed, ircd-behaviour-reliant, and, may I say, convoluted method to get around something that should be really simple... there are too many variables here and, based on past experience, it will probably not turn out well. The solution needs to be simple.

Adding more options to the interface is also not a solution. All that does is make the interface more complicated for bad reasons. This is something basic that should just work, not require an understanding by new users of how IRC works in order to tweak it to make it work in a reasonable way.

In the mean-time, I am going to add a check for the words "seconds" and "identify" for nickserv notices to ignore during logon. My apologies to the rest of the world's 7000 languages :-]

I am pretty sure SASL resolves this issue.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Khaled

I fully understand your reasoning here. Let's leave this here.

SASL does resolve this issue (for those servers that support SASL).

And I also believe that a script could be written to undertake the algorithm I suggested.

Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
SASL is much more common than it used to be, but there are some networks who either don't support it, or don't support it fully.

For example, Rizon is a large network which currently shows more than 10k users, and it doesn't seem to support SASL. I set config for Rizon to use their SSL port using SASL-Password as the method, and it didn't log me in. Also, related to SASL-External Certificate, even though their /whois reply tells me that I'm using a client certificate, it doesn't show my fingerprint, and their nickserv doesn't know what the CERT command is.

As for Snoonet's usage of MD5 for their fingerprints, apparently that's the default when a different hash isn't configured, so there may be other networks using MD5 for the same reason. It would also take a while for them to wean people off MD5 fingerprints, since it wouldn't be a good idea to suddenly invalidate everyone's fingerprints.


Link Copied to Clipboard