Developers of Sympa

[John-Paul Robinson <address@concealed>]

Hi,

I'm trying to figure out different ways to leverage the attributes_user
field in the users_table.  It's my understanding that this field is
populated automatically during user registration via SSO with one or more
CGI variables as defined in auth.conf via http_header_prefix. The
documentation states these attributes can be leveraged for authz using
user.attributes structure and in wwsympa templates.

I'm toying with an idea of maintaining a mapping between a supplied
attribute from the CGI environment and the email_user value.  If the
email_http_header value is missing from the CGI during authn, then the
user's email could be looked up via attributes_user.  This would operate
similarly to the current mechanism of using LDAP to lookup the email
address via the netid in do_sso_login().  The only difference is that the
netid->email mapping would be self-contained within sympa.  The netid 
would be stored in attributes_user and the do_sso_login() would search 
this column to find the correct email_user.

Of course, this relies on the mapping having been previously defined 
in sympa and introduces a small chicken-and-egg problem: if the user is 
not yet registered then there would be no mapping.  My thought is 
that this could be solved in two ways.  One could be a simple fall through 
to another method like the ldap lookup.  Another could be a fall through 
to a alternate registration method, like user-supplied email address.  

I'm particularly interested in the second option.  What I'm thinking is
that if the mapping is absent (first time registration) the user could be
authn'd and sympa has the netid but then prompts the user to enter their
email address and follows the confirm-with-password steps before
registration is completed.  To complete registration, sympa would store
the netid in attributes_user and the user-supplied-password-confirm email
address in email_user. This would give sympa the ability to accept a netid
but rely on the user to supply the email address.

This seems like it would be reasonably straight forward to implement and
hook in neatly with the existing netid->ldap-email mapping.  It also seems
to allow sympa to continue to use the email address as it's primary
internal identifier.

What I'm not sure about is if this would have a significant impact on 
other parts of sympa's operation.  

Comments are welcome. :)

Thanks,

~jpr