ALT+O -> Connect:
Nickname: KindOne
Alternative: KindTwo

"KindOne" is my account name and sasl plain will work fine.
But, if I reconnect due to crap internet and "KindOne" is still in use mIRC will use "KindTwo", that nick is not grouped into my account and causing sasl plain to fail.

I could group "KindTwo" into my account and this issue would not exist, but my theory is not everyone will have the alternative nick group, causing the failure.

Could it be possible to have an option to add the account name above the sasl password?


[18:57:41] -> localhost CAP LS
[18:57:41] -> localhost NICK KindOne
[18:57:41] -> localhost USER door 0 * :...
[18:57:41] <- :irc.foobar.com NOTICE * :*** Looking up your hostname...
[18:57:41] <- :irc.foobar.com NOTICE * :*** Checking Ident
[18:57:41] <- :irc.foobar.com NOTICE * :*** Got Ident response
[18:57:41] <- :irc.foobar.com NOTICE * :*** Couldn't look up your hostname
[18:57:41] <- :irc.foobar.com CAP * LS :account-notify away-notify cap-notify chghost extended-join multi-prefix sasl tls userhost-in-names
[18:57:41] -> localhost CAP REQ :account-notify
[18:57:41] -> localhost CAP REQ :away-notify
[18:57:41] -> localhost CAP REQ :chghost
[18:57:41] -> localhost CAP REQ :extended-join
[18:57:41] -> localhost CAP REQ :multi-prefix
[18:57:41] -> localhost CAP REQ :sasl
[18:57:41] -> localhost CAP REQ :userhost-in-names
[18:57:41] <- :irc.foobar.com CAP KindOne ACK :account-notify
[18:57:41] <- :irc.foobar.com CAP KindOne ACK :away-notify
[18:57:41] <- :irc.foobar.com CAP KindOne ACK :chghost
[18:57:42] <- :irc.foobar.com CAP KindOne ACK :extended-join
[18:57:43] <- :irc.foobar.com CAP KindOne ACK :multi-prefix
[18:57:44] <- :irc.foobar.com CAP KindOne ACK :sasl
[18:57:44] -> localhost AUTHENTICATE PLAIN
[18:57:45] <- :irc.foobar.com CAP KindOne ACK :userhost-in-names
[18:57:46] <- AUTHENTICATE +
// KindOneKindOnehunter2
[18:57:46] -> localhost AUTHENTICATE c29tZXJhbmRvbXRleHQ=
[18:57:47] <- :irc.foobar.com 900 KindOne KindOne!kindone@vhost.goes.here KindOne :You are now logged in as KindOne
[18:57:47] -> localhost CAP LIST
[18:57:47] -> localhost CAP END
[18:57:47] <- :irc.foobar.com 903 KindOne :SASL authentication successful
[18:57:48] <- :irc.foobar.com CAP KindOne LIST :account-notify away-notify chghost extended-join multi-prefix sasl userhost-in-names
[18:57:49] <- :irc.foobar.com NOTICE KindOne :*** You are exempt from flood limits
[18:57:49] <- :irc.foobar.com 001 KindOne :Welcome to the foobar Internet Relay Chat Network KindOne
[18:57:49] -> irc.foobar.com USERHOST KindOne
[18:57:49] <- :irc.foobar.com 002 KindOne :Your host is irc.foobar.com[irc.foobar.com/6667], running version charybdis-3.5.2


[18:58:37] -> localhost CAP LS
[18:58:37] -> localhost NICK KindOne
[18:58:37] -> localhost USER door 0 * :...
[18:58:37] <- :irc.foobar.com NOTICE * :*** Looking up your hostname...
[18:58:37] <- :irc.foobar.com NOTICE * :*** Checking Ident
[18:58:37] <- :irc.foobar.com NOTICE * :*** Couldn't look up your hostname
[18:58:37] <- :irc.foobar.com NOTICE * :*** Got Ident response
[18:58:37] <- :irc.foobar.com CAP * LS :account-notify away-notify cap-notify chghost extended-join multi-prefix sasl tls userhost-in-names
[18:58:37] -> localhost CAP REQ :account-notify
[18:58:37] -> localhost CAP REQ :away-notify
[18:58:37] -> localhost CAP REQ :chghost
[18:58:37] -> localhost CAP REQ :extended-join
[18:58:37] -> localhost CAP REQ :multi-prefix
[18:58:37] -> localhost CAP REQ :sasl
[18:58:37] -> localhost CAP REQ :userhost-in-names
[18:58:37] <- :irc.foobar.com 433 * KindOne :Nickname is already in use.
[18:58:37] -> localhost NICK KindTwo
[18:58:37] <- :irc.foobar.com CAP * ACK :account-notify
[18:58:37] <- :irc.foobar.com CAP * ACK :away-notify
[18:58:37] <- :irc.foobar.com CAP * ACK :chghost
[18:58:38] <- :irc.foobar.com CAP * ACK :extended-join
[18:58:39] <- :irc.foobar.com CAP * ACK :multi-prefix
[18:58:40] <- :irc.foobar.com CAP * ACK :sasl
[18:58:40] -> localhost AUTHENTICATE PLAIN
[18:58:41] <- :irc.foobar.com CAP * ACK :userhost-in-names
[18:58:43] <- AUTHENTICATE +
// KindTwoKindTwohunter2
[18:58:43] -> localhost AUTHENTICATE YmxhaGJsYWhibGFoYmxhaA==
[18:58:44] <- :irc.foobar.com 904 KindTwo :SASL authentication failed
[18:58:44] -> localhost CAP LIST
[18:58:44] -> localhost CAP END
[18:58:45] <- :irc.foobar.com CAP KindTwo LIST :account-notify away-notify chghost extended-join multi-prefix sasl userhost-in-names
[18:58:46] <- :irc.foobar.com NOTICE KindTwo :*** You are exempt from flood limits
[18:58:46] <- :irc.foobar.com 906 KindTwo :SASL authentication aborted
[18:58:46] <- :irc.foobar.com 001 KindTwo :Welcome to the foobar Internet Relay Chat Network KindTwo



Thank you for the sasl plain support!

The syntax for passing both your account name and your password is account:PaSsWorD as your password. This has always been the case for authenticating with NickServ via the PASS method (15 years?). And it's still the syntax clients use for SASL authentication via single parameter (password field).

It might be more user friendly to add an extra box for User Name or Account Name for the authentication section, to go along with Password.

If this is done, I request that the Password field still be parsed for account:PaSsWorD if the Account field is left blank. People are often instructed to put account:PaSsWorD "as their password." ZNC. Scripts. Existing mIRC and generic client tutorials. etc. Also, the Password field is ******'d out; hiding "account" names that might contain sensitive information about the ZNC.

Edit:

Er. I stand corrected. mIRC isn't actually correctly parsing the account vs password for the AUTHENTICATION $encoded()== message with SASL /CAP. It should check if ':' exists and grab the account name from the left of the first occurrence of ':' and pass the rest as the password. This does mean that passwords cannot contain a ':' of their own unless the user's account name is passed in this fashion. All the more reason for adding an Account GUI text field.

I am not clear on what would happen in the case where you try to login with an account and password using a different nickname. Aren't these tied to a specific, registered nickname?

What would happen if you connected with your registered nickname, logged into it using SASL and then, as with your situation, connected a second client, failed to login because the nickname was in use, used a second nickname, and then used an account and password connected to the first nickname?

Would the IRC server disconnect your first connection and change your second connection to use your registered nickname?

Do all IRC networks handle this in the same way?

I interpreted it as "Account Name != Nickname", so my script isn't sending the current nick (which may change) but an "Account" name stored elsewhere.
Hasn't failed me yet on various networks that support SASL, so I'd assume they're not the same in general.
Most of those networks (if not all, would have to check) have a separate numeric (raw 330 if I'm not mistaken) to return such an account name. First saw this with Quakenet (where the Nick is not tied into the account) and others automagically worked by handling 330 (even though they use NickServ or similar, which is essentially and historically treated like an account); but that could be a coincidence.

Your preferred nickname doesn't necessarily need to be tied to your account name, on a great many/most networks. Indeed, you can usually change nicknames without losing your 'Logged In' state. Some networks might log you out.

If you changed nicknames, your Main Nickname or Alternate Nickname might have changed within mIRC's settings (depending on preferences).

In most cases, people do choose their primary nickname as their account name.

Usually, the matching nickname cannot be 'ungrouped' or detached from an account without first renaming or dropping the account.

You can usually group multiple nicknames to an account, and this often allows you to utilize those alternate nicknames as substitution for your account name, for use as your login credentials. In KindOne's case, grouping KindTwo to his account would let him log in. Otherwise, he'd have to explicitly specify KindOne in his login credentials while sitting on the nickname KindTwo.

You can often log into your account while using any unregistered nickname, assuming you provide both account name and password in the login attempt, since your account name can't be implied from any unregistered and ungrouped nickname.

People often use scripts to log in under a randomized alternate nickname so they don't have to wait for their ghost(s) to die. Once logged in under their account (while using a random nickname), they can ghost kill (regain) their primary nickname.

All these cases I mentioned are accurate with Freenode and/or other networks I also frequent.

Now let's talk about ZNC, and other bouncers. Your Account name is usually both a combination of your proxy ownership credentials, and the IRC network you wish to be connected to. This is because ZNC reuse the same IP:PORT combination. Raccoon/freenode as my Account name would tell ZNC that I want to connect to freenode instead of EFnet.

On this note, I recall mIRC having an issue creating two server entries with the same IP or DNS name. I believe some tricks to get around this were manually creating duplicate entries in the servers.ini file via notepad, or alternating the CaSe.oF.tHe.dNs.NaMe, or choosing an alternate subdomain from their list of vanity hosts, and other similar string hacks to get around mIRC denying duplicate server entries. I'm not sure whether these tricks are still necessary today, but they shouldn't need to be.

I have extended the SASL routine to check for the account:password format in the password. If it sees a colon in the password, it will assume it is in an account:password format and will authenticate SASL using them. If the server replies that authentication failed, mIRC will try authenticating again using the whole word as a password, in case someone intentionally used a colon in their password. This will be in the next beta.

Okay, I just tested this (with the new beta that parses the account:password format) by connecting to the same server twice and the second connection used my alternate nickname and logged in successfully. My first client then received a notice telling it that someone had logged in authenticating with the same credentials. So that all seems fine.