91 lines
3.8 KiB
Plaintext
91 lines
3.8 KiB
Plaintext
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.
|
|
|