Login-on-Connect Documentation
Last updated 29 Jun 2014 by Andromeda

1. LOC is a feature intended to allow a client to log into services before
they are fully connected to the network. For networks that do not set +x
by default, this is a nice little security bonus as you are cloaked before
you even finish connecting. Malicious users, /ISON, /USERIP, and low latency
can reveal it's real host/IP before the user has a chance to connect and set
+x on themself.

2. Client<->Server:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The PASS command works as follows...

Syntax:
PASS [optional I:Line password] [/Service Nick]/Account/Password

Example:
PASS /Andromeda/ThisIsMyPassword

mIRC Syntax:
/server irc.afternet.org:6667 /AuthServ/Andromeda/ThisIsMyPassword

The way LOC works, it sends the account name and password to the default
service specified in the configuration file or if specified, the service
nick included within the syntax.

If the client sends such a password message, after sending NICK,
USER and PONG, it's username/passphrase are sent to the specified bot
for validation, while holding the client in the 'registration' state.
If the authentication succeeds, the client's account and umode +x are set,
after which he is introduced to the network, continuing the regular connect
phase. If authentication fails (or the bot is not on the network), the user
is given a chance to retry (they can do this by sending another PASS command),
or to disconnect from the server. If the user wishes to connect without a
hidden hostmask, he can send a PASS command with no parameters.

3. iAuthd<->LOC:
~~~~~~~~~~~~~~~~~~~~~~~
When a network is using iAuthd with Nefarious 2 for scanning incoming connections
for potential malicious users and other threats, Using LOC can bypass the iAuthd
scan process entirely. This is useful if a user's host is listed in any DNSBL in
use within the network.

4. Server<->Server:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ACCOUNT message now has the following syntax:

Auth check: 
<client's server numeric> AC <bot's numeric> C <request-id> <username> :<passphrase>

Host check:
<client's server numeric> AC <bot's numeric> H <request-id> <ident>@<host>:<ip> <username> :<passphrase>
If the host contains :'s it should be surrounded by []. Useful for determining
IPv6 vs IPv4 or unresolved rDNS's. Generally keeping things nice and tidy or
easier to work with.

Fingerprint check:
<client's server numeric> AC <bot's numeric> S <request-id> <ident>@<host>:<ip> <sslfingerprint> <username> :<passphrase>

Servers send this message to request a service bot to authenticate the client.
<request-id> is not processed neither by the servers along the way nor the
service bot. Currently this is:
	 '.' <fd> '.' <cookie>
The inital '.' makes sure that the ID is not a valid integer, which is part of
the hack required to support old-style ACCOUNT messages. The cookie is used to
validate replies, since the user might disconnect and the fd be reused before
the reply comes back from the service. Hubs propagate this message as-is
towards the service bot, not unlike PRIVMSG.

Auth reply:
<bot's server numeric> AC <client's server numeric> A|D <request-id>

Service bots send this in reply to an 'auth check' message from a server.
"A" stands for "accepted", "D" for "denied". Again, hubs will have
to proagate this message back to the client's server.

Remote auth:
<bot's server numeric> AC <client numeric> R <account> [<timestamp>]

This is the current message used by service bots to announce the network
that a user has logged in. The old format is still supported:
<bot's server numeric> AC <client numeric> <account> [<timestamp>]

5. IRCu Configuration:
~~~~~~~~~~~~~~~~~~~~~~~~~
FEAT_LOGIN_ON_CONNECT (default FALSE) will specify whether
ircu will honour the login scheme as specified above for the PASS command.
ircu will route ACCOUNT messages anyway, regardless of this feature's value.