|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
If your server has been set to use nickserv with a password; and...
If you put a channel in your favourites and mark it as "Join on connect" and if the channel is mode +r (which means "you need to be identified with services" before joining) ...
Then mIRC attempts to join the channel before identification has succeeded.
You cannot tell in advance whether the channel is mode +r, so before autojoining any channel on connect, if the server is defined as using nickserv identify then mIRC needs to have sent the nickserv identify and either received a "-NickServ- You are now identified $me" notice or waited for a period of time to elapse (say 1s) before attempting to join the channel.
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Perhaps we can add a 3 second delay to mIRC's auto join favorites.
This should resolve most considerations with NickServ Auth latency, Performs and other On Connect prep-work.
This same delay might also be added to mIRC's re-joining of channels on reconnect.
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
A 3s delay (if the connection has nickserv authentication) is the simplest solution. (I agree that 3s is probably a better default than 1s - or it could be a setting.)
But it would be even better if mIRC watched for the Nickserv "identified" message in order not to wait until the 3s has elapsed - but in case it can't recognise the nickserv message, if it has received it in 3s then it should attempt a join anyway. (If we will react to nickserv's notice, perhaps the default timeout should be a little longer - say 5s instead.)
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
In my opinion there should be a setting or option if you can activate or deactivate, in the mIRC Favorites dialog, where autojoin is performed only just the confirmation msg that the nickname is identified in the services. Perhaps we can add a 3 second delay to mIRC's auto join favorites.
This should resolve most considerations with NickServ Auth latency, Performs and other On Connect prep-work.
This same delay might also be added to mIRC's re-joining of channels on reconnect.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Dec 2002
Posts: 5,473
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,473 |
But it would be even better if mIRC watched for the Nickserv "identified" message I try to avoid solutions that depend on wording. Not only do different networks use different wording but they can change the wording and format from ircd version to version. In addition, this assumes that the wording is in English, which it may not be. Unfortunately, I have been forced to check for specific phrases in English to parse some numerics due to different ircds using the same numerics for different features. It's not a pretty solution. In this case, looking for a message from nickserv to confirm that a user has been identified is not ideal. Such a reply should really have been a numeric to make it clear to the client what has happened. mIRC rejoins channels, and triggers the perform section, as well as initiating other features, only after it has received the MOTD. I could make mIRC wait for three seconds after the MOTD before doing this to get around the nickserv limitation but this would affect all users and all connections. It would not be possible to make mIRC do this only if the connection has Nickserv set. Nickserv can identify your connection from an SSL certificate, two SASL formats, two Nickserv formats, and a password format specific to that server.
|
|
|
|
Joined: Nov 2004
Posts: 842
Hoopy frood
|
Hoopy frood
Joined: Nov 2004
Posts: 842 |
What about /who <self> %a if the IRCd supports WHOX?
What do you do at the end of the world? Are you busy? Will you save us?
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
[quote]mIRC rejoins channels, and triggers the perform section, as well as initiating other features, only after it has received the MOTD. I could make mIRC wait for three seconds after the MOTD before doing this to get around the nickserv limitation but this would affect all users and all connections. Another alternative solution: And you could not get around this situation using $usermodes? For example I connect to a network and having for example a check of the mIRC Favorites dialog activates mIRC only executing the autojoin -n command if the identifier $usermodes returns the mode +r. I think this mode is the most common in all networks and would not depend on nickserv.
Last edited by Tiago; 28/09/18 06:58 PM.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
I think it is a good alternative to get around this situation so there is no need to put a wait time for mIRC to enter the channels if we have an option that we can activate or deactivate in the favorite mIRC dialog for example:
(check) Only after identification
and with this active option, mIRC only entered the channels if it returned from the identifier $usermodes the mode +r that corresponds to the identification of the nickname.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
1. On freenode I have a registered nick, but $usermode +r is not set. So I am not sure that this will work reliably.
2. For NICKSERV identification by mIRC as part of the server configuration (as opposed to using a script or perform to do it), then mIRC knows it has requested authentication by NICKSERV and all it needs to do is to wait for a NOTICE of any form from NICKSERV before attempting a join.
It does not need to worry about whether the authentication actually succeeded before attempting a join - if it failed and channel is +r then the join will fail because the authentication failed. If it succeeded then the join will work.
I cannot comment on other authentication methods such as SASL.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
P.S. Just tested SASL and you get a 903 message for successful authentication. This is also quick - it comes before the MOTD.
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Tiago: Your first goal is to stop worrying about the Favorites auto-join option, since the same behavior considerations must also be made for [re]connect [re]joins, which supersedes Favorites autojoin. So we're not talking about Favorites anymore in this thread, we're talking about all connect/reconnect server-j_join/favjoin/rejoins. 100% detached from Favorites or any options toggled within Favorites.
Secondly, there are 4 or 5 or 6 different usermode +r alternatives, so $usermodes is a non-starter.
Nickname and Channel services are almost entirely a non-anti-unstandard in IRC, with the only exception being SASL auth, and pseudo-standard PASS auth, and defacto-standard /NICKSERV auth. You will never find an acceptable IsAuth solution until a standard is both proposed and adopted, which has not happened.
Khaled: I am personally fine with subjecting everybody to a 3 second delay in auto joining channels. There is scarcely a situation where sync time is terribly less then that anyway, and it may play out that all IRC channels benefit from a less aggressive connect_join time where users are experiencing crap-tastic connection drops, send_q flooding, or delayed oper k-lines and proxy detection bans. Less channel flooding as people join/quit/join/quit mere seconds apart. Certainly, we would see a drop in "Quit: Logged In" or "Quit: Changing Vhost" style [fake/virtual] quit messages from people authenticating late.
I would encourage all clients to add a 3 second delay between 001...005 or 376 and auto-[re]joins. (reset the 3 second timer for each matching numeric encountered)
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
Nickname and Channel services are almost entirely a non-anti-unstandard in IRC, with the only exception being SASL auth, and pseudo-standard PASS auth, and defacto-standard /NICKSERV auth. You will never find an acceptable IsAuth solution until a standard is both proposed and adopted, which has not happened. I agree that you cannot hope for mIRC to recognise every authentication method on every IRCD ever written. My request is limited only to those authentication methods already recognised by mIRC by offering authentication in the server definition - and only to delaying autojoin to channels until it receives some response to the authentication request or a timeout expires. I think this is possible.
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
Tiago: Your first goal is to stop worrying about the Favorites auto-join option, since the same behavior considerations must also be made for [re]connect [re]joins, which supersedes Favorites autojoin. So we're not talking about Favorites anymore in this thread, we're talking about all connect/reconnect server-j_join/favjoin/rejoins. 100% detached from Favorites or any options toggled within Favorites.
Secondly, there are 4 or 5 or 6 different usermode +r alternatives, so $usermodes is a non-starter.
Nickname and Channel services are almost entirely a non-anti-unstandard in IRC, with the only exception being SASL auth, and pseudo-standard PASS auth, and defacto-standard /NICKSERV auth. You will never find an acceptable IsAuth solution until a standard is both proposed and adopted, which has not happened.
Khaled: I am personally fine with subjecting everybody to a 3 second delay in auto joining channels. There is scarcely a situation where sync time is terribly less then that anyway, and it may play out that all IRC channels benefit from a less aggressive connect_join time where users are experiencing crap-tastic connection drops, send_q flooding, or delayed oper k-lines and proxy detection bans. Less channel flooding as people join/quit/join/quit mere seconds apart. Certainly, we would see a drop in "Quit: Logged In" or "Quit: Changing Vhost" style [fake/virtual] quit messages from people authenticating late.
I would encourage all clients to add a 3 second delay between 001...005 or 376 and auto-[re]joins. (reset the 3 second timer for each matching numeric encountered) I do not think you need to talk to me like that, because I did not offend anyone by suggesting anything. I think this is a forum and we can all give suggestions whatever, even because with the same right that you think you have the right to call my attention, I could do the same with your conduct and how to talk to me, but I will not do it because I do not waste time with people with no education at all.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Sorry, it wasn't intended to be offensive, just matter of fact. Poorly worded. I should have said the 'first issue is' or such.
<--- This idiot relies on too many idioms.
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Dec 2002
Posts: 5,473
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,473 |
I am personally fine with subjecting everybody to a 3 second delay in auto joining channels. I have been looking into this on Freenode. The nickserv identification message takes about 6 seconds to arrive after the end of the MOTD. So mIRC would need to wait at least 6 seconds - but probably more like 10 seconds to be safe. That said, it appears that servers queue the identification request in the background while processing other server messages for that user, so the amount of time it takes to identify a user seems to depend on how busy a server is - identification could take 60 seconds for all we know. I could make mIRC wait for a NOTICE from "NickServ" with the words "You are now identified for" - but this would not be ideal because this may not be standard across networks, and it uses English, which will not work on non-English networks. It would not be enough to wait for just any NOTICE from NickServ. When I connect to Freenode, I almost always receive a "-NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>" before I receive a second NOTICE "You are now identified". So mIRC would need to check the wording.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
I have been looking into this on Freenode and the nickserv identification message takes about 6 seconds to arrive. So mIRC would need to wait at least 6 seconds - but ... identification could take 60 seconds for all we know.
I could make mIRC wait for a NOTICE from "NickServ" with the words "You are now identified for" - which would not be fine because this may not be standard across networks and uses English, which will not work on non-English networks.
It would not be enough to wait for just any NOTICE from NickServ. When I connect to Freenode, I almost always receive a "-NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>" before I receive a second NOTICE "You are now identified". So mIRC would need to check the wording. @Khaled - I understand your logic here but having digested this I would suggest the following: 1. Ignore any Notice from NICKSERV which has "/msg NICKSERV" in it - this is unlikely to be different in different languages. 2. Assume that any Notice which doesn't have this is either an authorised / un-authorised message - and either way use this to trigger the autojoin attempt. 3. Bearing in mind that in normal operation you will get a 903 SASL response or NICKSERV Notice, it is very unlikely that the timeout will ever be triggered - it will only be if you have misconfigured an SASL/Nickserv for a server which doesn't support it or e.g. if the server's NICKSERV is down. On this basis a fixed timeout of 60s or 30s might well be acceptable - or we could allow the user to change it via another setting in the Edit Server pop-up. P.S. Also, since SASL support is announced in a CAP before you send an SASL / NICKSERV password, how about a (default?) option which automatically decides whether to send an SASL or /msg NICKSERV password depending on whether the CAP SASL is sent to mIRC. :-)
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
Why don't you do something more clever?
As most (about 90%) of services when you identify you get "+r" usermode, you can start auto-join if you receive that usermode flag instead of NOTICE from nickserv that if i use an other services language non-english it may be broken.
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
And even if you put mIRC checking the NickServ text in several languages, I think it would not be that bad and not impossible. For example in PTnet and PTirc where I am IRCop the NickServ call takes less than 3 seconds. So I think you should put the NickServ text in several languages in the mIRC database.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
However, if you are looking for a simpler solution and I believe it is effective and that it minimizes this problem to all users on any network, then you have to create an option in the mIRC Favorites dialog that allows you to customize the time of entry into the channels when we do the network connection.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
Joined: Jul 2014
Posts: 327
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Jul 2014
Posts: 327 |
Why don't you do something more clever?
As most (about 90%) of services when you identify you get "+r" usermode, you can start auto-join if you receive that usermode flag instead of NOTICE from nickserv that if i use an other services language non-english it may be broken. Excelent idea. I had already suggested that but they would not listen.
TECO irc.PTirc.org (Co-Admin)
|
|
|
|
|