[IRCServices Coding] Auth Module - SETAUTH command suggestion

[Mark Hetherington]

One thing that seems to be missing from the AUTH modules, is the ability to 
put a nick into auth mode. The reasons that I feel this command is required 
are listed below:

1) We have a number of nicknames that were registered before the 
introduction of the AUTH modules, so although we have always insisted on 
email addresses, not all are verified. Some are obviously made up purely 
for the purpose of registration. At present, the only guaranteed solution 
is to drop the nick name and force it to be registered under the new AUTH 
system. However, since this would be more than a minor inconvenience for 
some users as it dropped channels, linked nicks and access rights in 
channels, it is something that I would prefer a more user friendly solution 
to. For anyone changing over from an older version of services or a 
competitor without nickname validation, a SETAUTH feature would be useful 
in validating existing registrations.

2) Services Admins are able to change the email address of a user without 
triggering the AUTH module. Unless the Services Admin manually verifies the 
address, or knows the address to be valid, this creates a situation where 
an email address can be entered into a new database which is not validated. 
A SETAUTH command would address this for an email address which cannot be 
verfied manually. This could be acheived by always triggering AUTH on set 
email, but since there are cases where auth may not be required, SETAUTH 
provides this as an option.

3) When importing users from another services database, for example during 
a network merge, again there is the potential for importing unvalidated 
addresses. SETAUTH would allow a Services Admin to flag nicknames as 
unauthorised so that validation could occur. Again, this could be 
automatically flagged during import, but as with 2, I think a command is 
better to make the AUTH optional. 

One issue with the command, is it would likely require an unlimited AUTH 
time (until normal nick expiration at least) since in scenario 3 above, it 
is possible that not all users would log on before the main AUTH expiry 
time kicked in. It seems that the SET EMAIL authorisation already works in 
this manner so this may be trivial to address. 


-- 
Mark.