> Let's not get carried away here. What we're already doing is hard
> enough; this would just make things orders of magnitude more difficult.
> --
> Kevin L. Mitchell <[EMAIL PROTECTED]>
A simple approach(which I am prepared to code at some stage
if no-one has a problem with it) would be to do:
Logins to services occur at runtime using the traditional
PASS command using a format like this:
PASS
:local=ilinepasswd&oper=opername:operpassword&users=usersname:userspasswd:h&admins=adminsname:adminspassword
where local & oper are special values for the auth {} block
password, oper is for the operator {} block, and everything
else is looked up on the services list.
The :h after userspassword indicates that the username
service's account.serviceshost should be used for host hiding.
All services are registered by 1 or more U: lined servers
using the SERVICE message:
SERVICE svcname[ :hostprefix]
where the host prefix is optional and only included on
services that support name hiding. The svcname & host prefix are stored in
a linked list or possibly a hashtable, along with a pointer
to the server that registered the service. A linked list of
services registered by this server is attached to each
server. When a server exits, the pointer is set to NULL but
the service is not removed. SERVICE commands are propagated
after the server they are behind is introduced, or if they
are behind no server anymore, they are propagated using the
prefix of the introducing server(this is identified as being
distinct from a service because it is not U-lined). The only
way that a service can be removed from the network is using
the "SQUIT svcname" command, and this will only work if no server
"owns" the service, i.e. it has SQUIT away itself. This
variant of the SQUIT command will be limited to network
administrators, and will require the users linked list to be
walked globally to ensure no users still have a pointer to
the service struct.
After a client connects and sends NICK/USER, they are given
a numeric nick, and the local= and oper= parts of their PASS
line are processed if present. However, if other svcname=
are present, they are not registered immediately, instead
the registration is deferred and the following message is
sent:
AUTH svcname id username pass
to the pointer found by looking up svcname, or if it is
NULL, the user is given an error, and processing moves on to
the next service login.
When a server receives the AUTH command from another server,
it looks up the svcname itself, and if it doesn't find it,
or the server owning it is NULL or the from of the server
owning it is the server the message was received from, an
error is sent back using AUTHBAD(see below). The server must
not validate the id(yxx) of the client because it has not
yet been introduced to the net.
When the message makes it to the service server, it checks
the password and if it is good, it sends:
AUTHOK svcname id
the message is propagated by using the y(i.e. server) part
of the id(yxx) field.
If the password is bad, it sends an AUTHBAD message:
AUTHBAD svcname id :reason
where reason might be "Invalid username or password" etc...
If a server receives an AUTHBAD message for an id it owns,
it will give them the reason and exit them. If it receives
an AUTHOK message for all the services they attempted to log
into(which are stored on a linked list), it will register
them, and after their nickname has been propagated, using
the masked host if appropriate, to the net, send an ACCOUNT command:
ACCOUNT yxx accountname[ service]
Servers will assume service is the special implicit service
users with a preprocessor-defined host if no service is
given on the account command.
The user will automatically be set +x if they requested any
service logins.
This will be enabled in phases by features. Firstly, only
AUTH, AUTHOK, AUTHBAD propagation will be enabled, as well
as understanding the extra parameter to ACCOUNT.
Later, support of service logins on the extended password
command will be enabled.
I haven't started coding this so if anyone has any comments
please add to/change my protocol ideas if you can make it
better.
