software/!RELEASES/ircservices/achurch.org/services/lists/ircservices-coding/2002/000264.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
   2 <HTML>
   3  <HEAD>
   4    <TITLE> [IRCServices Coding] Auth Module - SETAUTH command suggestion
   5    </TITLE>
   6    <LINK REL="Index" HREF="index.html" >
   7    <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Auth%20Module%20-%20SETAUTH%20command%20suggestion&In-Reply-To=">
   8    <META NAME="robots" CONTENT="index,nofollow">
   9    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
  10    <LINK REL="Previous"  HREF="000263.html">
  11    <LINK REL="Next"  HREF="000265.html">
  12  </HEAD>
  13  <BODY BGCOLOR="#ffffff">
  14    <H1>[IRCServices Coding] Auth Module - SETAUTH command suggestion</H1>
  15     <B>Mark Hetherington</B>
  16     <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Auth%20Module%20-%20SETAUTH%20command%20suggestion&In-Reply-To="
  17        TITLE="[IRCServices Coding] Auth Module - SETAUTH command suggestion">mark at ctcp.net
  18        </A><BR>
  19     <I>Wed Feb 13 13:17:43 PST 2002</I>
  20     <P><UL>
  21         <LI>Previous message: <A HREF="000263.html">[IRCServices Coding] Idea
  22 </A></li>
  23         <LI>Next message: <A HREF="000265.html">[IRCServices Coding] TODO update
  24 </A></li>
  25          <LI> <B>Messages sorted by:</B>
  26               <a href="date.html#264">[ date ]</a>
  27               <a href="thread.html#264">[ thread ]</a>
  28               <a href="subject.html#264">[ subject ]</a>
  29               <a href="author.html#264">[ author ]</a>
  30          </LI>
  31        </UL>
  32     <HR>
  33 <!--beginarticle-->
  34 <PRE>One thing that seems to be missing from the AUTH modules, is the ability to
  35 put a nick into auth mode. The reasons that I feel this command is required
  36 are listed below:
  37
  38 1) We have a number of nicknames that were registered before the
  39 introduction of the AUTH modules, so although we have always insisted on
  40 email addresses, not all are verified. Some are obviously made up purely
  41 for the purpose of registration. At present, the only guaranteed solution
  42 is to drop the nick name and force it to be registered under the new AUTH
  43 system. However, since this would be more than a minor inconvenience for
  44 some users as it dropped channels, linked nicks and access rights in
  45 channels, it is something that I would prefer a more user friendly solution
  46 to. For anyone changing over from an older version of services or a
  47 competitor without nickname validation, a SETAUTH feature would be useful
  48 in validating existing registrations.
  49
  50 2) Services Admins are able to change the email address of a user without
  51 triggering the AUTH module. Unless the Services Admin manually verifies the
  52 address, or knows the address to be valid, this creates a situation where
  53 an email address can be entered into a new database which is not validated.
  54 A SETAUTH command would address this for an email address which cannot be
  55 verfied manually. This could be acheived by always triggering AUTH on set
  56 email, but since there are cases where auth may not be required, SETAUTH
  57 provides this as an option.
  58
  59 3) When importing users from another services database, for example during
  60 a network merge, again there is the potential for importing unvalidated
  61 addresses. SETAUTH would allow a Services Admin to flag nicknames as
  62 unauthorised so that validation could occur. Again, this could be
  63 automatically flagged during import, but as with 2, I think a command is
  64 better to make the AUTH optional.
  65
  66 One issue with the command, is it would likely require an unlimited AUTH
  67 time (until normal nick expiration at least) since in scenario 3 above, it
  68 is possible that not all users would log on before the main AUTH expiry
  69 time kicked in. It seems that the SET EMAIL authorisation already works in
  70 this manner so this may be trivial to address.
  71
  72
  73 --
  74 Mark.
  75
  76
  77
  78 </PRE>
  79
  80 <!--endarticle-->
  81     <HR>
  82     <P><UL>
  83         <!--threads-->
  84         <LI>Previous message: <A HREF="000263.html">[IRCServices Coding] Idea
  85 </A></li>
  86         <LI>Next message: <A HREF="000265.html">[IRCServices Coding] TODO update
  87 </A></li>
  88          <LI> <B>Messages sorted by:</B>
  89               <a href="date.html#264">[ date ]</a>
  90               <a href="thread.html#264">[ thread ]</a>
  91               <a href="subject.html#264">[ subject ]</a>
  92               <a href="author.html#264">[ author ]</a>
  93          </LI>
  94        </UL>
  95
  96 </body></html>