[IRCServices Coding] Auth Module - SETAUTH command suggestion

[Andrew Church]

>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:

     Good idea, added (SETAUTH).

  --Andrew Church
    achurch at achurch.org
    http://achurch.org/

>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.
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding