[Mageia-sysadm] [LONG] sympa ( and web apps ) ldap authentication

Fri Nov 26 03:08:34 CET 2010

Le vendredi 26 novembre 2010 à 02:10 +0100, nicolas vigier a écrit :
+> On Fri, 26 Nov 2010, Michael Scherer wrote:
+> 
+> > 
+> > - find a way to ensure unicity of email for the secondary emails that
+> > user can enter. If possible, on the ldap level directly, but maybe doing
+> > it on catdap level would be enough. I would feel safer to have this at
+> > ldap level for obvious reasons of data integrity.
+> > 
+> > 
+> > - once we have enabled and checked it, and ensured that this is not a
+> > potential source of problem, enable the use of the secondary email as a
+> > login, in addition to username and primary email
+> > 
+> > ( this should not requires much patching of application, but if needed,
+> > same rule as previously apply ).
+> 
+> Is it really needed to allow users to enter secondary emails ? How will
+> they be used ?
+
+Nothing fancy as said before :
+
+- vcard like feature for those that want ( ie, nothing force people to
+enter them ). There is already provision of this in ldap schema, and I
+think that's something that people could want. At least, I would, but I
+could live without it.
+
+However among the 3 distribution DIT I checked :
+launchpad (ubuntu) does it ( but you have to be logged to see ),
+fas (fedora) doesn't , 
+and debian db do not show email and I do not have access to it to check.
+But I do not think it has any kind of email in their ldap, as the
+primary authentication system is gpg. 
+
+- additional mail that would be accepted when posting on sympa for
+people like me or nanar that use several mails, or for specific case
+like cross posting ( I use @mdv.org on mdv email, and @zarb.org on
+mageia ml, so cross posting is not possible for someone like me ).
+That's my pet peeve.
+
+- could ease people's life as they would use any of their mails ( ie no
+need to remember what mail they did use, as noted by nanar in this
+thread )
+
+But also note this is a secondary feature, ie one that we cannot enable
+right now, as we first need to check this is doable without too much
+work ( or doable with lots of work if someone does the work ). 
+
+So not having it would be ok too.
+
+-- 
+Michael Scherer
+
+