[irc.git] / software / RELEASES / ircservices / achurch.org / services / lists / ircservices-coding / 2002 / 000354.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [IRCServices Coding] Auth Module - SETAUTH command suggestion
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Auth%20Module%20-%20SETAUTH%20command%20suggestion&In-Reply-To=">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="000353.html">
   <LINK REL="Next"  HREF="000355.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[IRCServices Coding] Auth Module - SETAUTH command suggestion</H1>
    <B>Andrew Church</B> 
    <A HREF="mailto:ircservices-coding%40ircservices.za.net?Subject=%5BIRCServices%20Coding%5D%20Auth%20Module%20-%20SETAUTH%20command%20suggestion&In-Reply-To="
       TITLE="[IRCServices Coding] Auth Module - SETAUTH command suggestion">achurch at achurch.org
       </A><BR>
    <I>Thu Feb 28 00:23:48 PST 2002</I>
    <P><UL>
        <LI>Previous message: <A HREF="000353.html">[IRCServices Coding] Services 5.0a21 Slipping through the AUTH net...
</A></li>
        <LI>Next message: <A HREF="000355.html">[IRCServices Coding] Services 5.0 alpha 23 released
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#354">[ date ]</a>
              <a href="thread.html#354">[ thread ]</a>
              <a href="subject.html#354">[ subject ]</a>
              <a href="author.html#354">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>&gt;<i>One thing that seems to be missing from the AUTH modules, is the ability to 
</I>&gt;<i>put a nick into auth mode. The reasons that I feel this command is required 
</I>&gt;<i>are listed below:
</I>
     Good idea, added (SETAUTH).

  --Andrew Church
    <A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>
    <A HREF="http://achurch.org/">http://achurch.org/</A>

&gt;<i>1) We have a number of nicknames that were registered before the 
</I>&gt;<i>introduction of the AUTH modules, so although we have always insisted on 
</I>&gt;<i>email addresses, not all are verified. Some are obviously made up purely 
</I>&gt;<i>for the purpose of registration. At present, the only guaranteed solution 
</I>&gt;<i>is to drop the nick name and force it to be registered under the new AUTH 
</I>&gt;<i>system. However, since this would be more than a minor inconvenience for 
</I>&gt;<i>some users as it dropped channels, linked nicks and access rights in 
</I>&gt;<i>channels, it is something that I would prefer a more user friendly solution 
</I>&gt;<i>to. For anyone changing over from an older version of services or a 
</I>&gt;<i>competitor without nickname validation, a SETAUTH feature would be useful 
</I>&gt;<i>in validating existing registrations.
</I>&gt;<i>
</I>&gt;<i>2) Services Admins are able to change the email address of a user without 
</I>&gt;<i>triggering the AUTH module. Unless the Services Admin manually verifies the 
</I>&gt;<i>address, or knows the address to be valid, this creates a situation where 
</I>&gt;<i>an email address can be entered into a new database which is not validated. 
</I>&gt;<i>A SETAUTH command would address this for an email address which cannot be 
</I>&gt;<i>verfied manually. This could be acheived by always triggering AUTH on set 
</I>&gt;<i>email, but since there are cases where auth may not be required, SETAUTH 
</I>&gt;<i>provides this as an option.
</I>&gt;<i>
</I>&gt;<i>3) When importing users from another services database, for example during 
</I>&gt;<i>a network merge, again there is the potential for importing unvalidated 
</I>&gt;<i>addresses. SETAUTH would allow a Services Admin to flag nicknames as 
</I>&gt;<i>unauthorised so that validation could occur. Again, this could be 
</I>&gt;<i>automatically flagged during import, but as with 2, I think a command is 
</I>&gt;<i>better to make the AUTH optional. 
</I>&gt;<i>
</I>&gt;<i>One issue with the command, is it would likely require an unlimited AUTH 
</I>&gt;<i>time (until normal nick expiration at least) since in scenario 3 above, it 
</I>&gt;<i>is possible that not all users would log on before the main AUTH expiry 
</I>&gt;<i>time kicked in. It seems that the SET EMAIL authorisation already works in 
</I>&gt;<i>this manner so this may be trivial to address. 
</I>&gt;<i>
</I>&gt;<i>
</I>&gt;<i>-- 
</I>&gt;<i>Mark.
</I>&gt;<i>
</I>&gt;<i>
</I>&gt;<i>------------------------------------------------------------------
</I>&gt;<i>To unsubscribe or change your subscription options, visit:
</I>&gt;<i><A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A>
</I>
</PRE>

<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="000353.html">[IRCServices Coding] Services 5.0a21 Slipping through the AUTH net...
</A></li>
	<LI>Next message: <A HREF="000355.html">[IRCServices Coding] Services 5.0 alpha 23 released
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#354">[ date ]</a>
              <a href="thread.html#354">[ thread ]</a>
              <a href="subject.html#354">[ subject ]</a>
              <a href="author.html#354">[ author ]</a>
         </LI>
       </UL>

</body></html>
Commit	Line	Data
3bd189cb JR	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="000353.html">
	11	<LINK REL="Next" HREF="000355.html">
	12	</HEAD>
	13	<BODY BGCOLOR="#ffffff">
	14	<H1>[IRCServices Coding] Auth Module - SETAUTH command suggestion</H1>
	15	<B>Andrew Church</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">achurch at achurch.org
	18	</A><BR>
	19	<I>Thu Feb 28 00:23:48 PST 2002</I>
	20	<P><UL>
	21	<LI>Previous message: <A HREF="000353.html">[IRCServices Coding] Services 5.0a21 Slipping through the AUTH net...
	22	</A></li>
	23	<LI>Next message: <A HREF="000355.html">[IRCServices Coding] Services 5.0 alpha 23 released
	24	</A></li>
	25	<LI> <B>Messages sorted by:</B>
	26	<a href="date.html#354">[ date ]</a>
	27	<a href="thread.html#354">[ thread ]</a>
	28	<a href="subject.html#354">[ subject ]</a>
	29	<a href="author.html#354">[ author ]</a>
	30	</LI>
	31	</UL>
	32	<HR>
	33	<!--beginarticle-->
	34	<PRE>><i>One thing that seems to be missing from the AUTH modules, is the ability to
	35	</I>><i>put a nick into auth mode. The reasons that I feel this command is required
	36	</I>><i>are listed below:
	37	</I>
	38	Good idea, added (SETAUTH).
	39
	40	--Andrew Church
	41	<A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">achurch at achurch.org</A>
	42	<A HREF="http://achurch.org/">http://achurch.org/</A>
	43
	44	><i>1) We have a number of nicknames that were registered before the
	45	</I>><i>introduction of the AUTH modules, so although we have always insisted on
	46	</I>><i>email addresses, not all are verified. Some are obviously made up purely
	47	</I>><i>for the purpose of registration. At present, the only guaranteed solution
	48	</I>><i>is to drop the nick name and force it to be registered under the new AUTH
	49	</I>><i>system. However, since this would be more than a minor inconvenience for
	50	</I>><i>some users as it dropped channels, linked nicks and access rights in
	51	</I>><i>channels, it is something that I would prefer a more user friendly solution
	52	</I>><i>to. For anyone changing over from an older version of services or a
	53	</I>><i>competitor without nickname validation, a SETAUTH feature would be useful
	54	</I>><i>in validating existing registrations.
	55	</I>><i>
	56	</I>><i>2) Services Admins are able to change the email address of a user without
	57	</I>><i>triggering the AUTH module. Unless the Services Admin manually verifies the
	58	</I>><i>address, or knows the address to be valid, this creates a situation where
	59	</I>><i>an email address can be entered into a new database which is not validated.
	60	</I>><i>A SETAUTH command would address this for an email address which cannot be
	61	</I>><i>verfied manually. This could be acheived by always triggering AUTH on set
	62	</I>><i>email, but since there are cases where auth may not be required, SETAUTH
	63	</I>><i>provides this as an option.
	64	</I>><i>
65	</I>><i>3) When importing users from another services database, for example during
66	</I>><i>a network merge, again there is the potential for importing unvalidated
67	</I>><i>addresses. SETAUTH would allow a Services Admin to flag nicknames as
68	</I>><i>unauthorised so that validation could occur. Again, this could be
69	</I>><i>automatically flagged during import, but as with 2, I think a command is
70	</I>><i>better to make the AUTH optional.
71	</I>><i>
72	</I>><i>One issue with the command, is it would likely require an unlimited AUTH
73	</I>><i>time (until normal nick expiration at least) since in scenario 3 above, it
74	</I>><i>is possible that not all users would log on before the main AUTH expiry
75	</I>><i>time kicked in. It seems that the SET EMAIL authorisation already works in
76	</I>><i>this manner so this may be trivial to address.
77	</I>><i>
78	</I>><i>
79	</I>><i>--
80	</I>><i>Mark.
81	</I>><i>
82	</I>><i>
83	</I>><i>------------------------------------------------------------------
84	</I>><i>To unsubscribe or change your subscription options, visit:
85	</I>><i><A HREF="http://www.ircservices.za.net/mailman/listinfo/ircservices-coding">http://www.ircservices.za.net/mailman/listinfo/ircservices-coding</A>
86	</I>
87	</PRE>
88
89	<!--endarticle-->
90	<HR>
91	<P><UL>
92	<!--threads-->
93	<LI>Previous message: <A HREF="000353.html">[IRCServices Coding] Services 5.0a21 Slipping through the AUTH net...
94	</A></li>
95	<LI>Next message: <A HREF="000355.html">[IRCServices Coding] Services 5.0 alpha 23 released
96	</A></li>
97	<LI> <B>Messages sorted by:</B>
98	<a href="date.html#354">[ date ]</a>
99	<a href="thread.html#354">[ thread ]</a>
100	<a href="subject.html#354">[ subject ]</a>
101	<a href="author.html#354">[ author ]</a>
102	</LI>
103	</UL>
104
105	</body></html>