[SAC] Wiki, Membership app form & LDAP

[Jorge Gustavo]

Hi Martin,

Thanks for the clear explanation.

Maybe email addresses might match better than usernames. Can we use the 
email addresses in LDAP and in the Wiki to see how many we can match?

I won't be able to do it right now, but tomorrow I can try to see the if 
the best match is between usernames or email addresses.

Meanwhile, I've started to use LDAP authentication in our local 
chapter's mediawiki, and the LDAP extension works great. It can read 
LDAP and update LDAP. Users can change passwords, for example, in the 
regular wiki way, and passwords are updated on the LDAP.

On Drupal 7.x, only authentication (read) is working "out of the box", 
with the LDAP extension. The same with wordpress: authentication is 
working very well, but no LDAP updates "out of the box". Only MediaWiki 
is updating the LDAP.

Regards,

Jorge Gustavo

On 28-09-2011 10:41, Martin Spott wrote:
> On Sat, Sep 17, 2011 at 05:02:32PM -0600, Seven (aka Arnulf) wrote:
>
>> Could you please repeat your suggestion how to deal with the existing
>> Wiki accounts, just so that Jorge understand it?
>
> I think we're having two options, one which is limited just to a
> technical solution, another takes the 'social' implications into
> account  :-)
> The goal is to map current Wiki users to the corresponding counterpart
> in our LDAP directory.  Thus we need to know about the proper username
> pairings - for solving two issues, of which one may be considered as
> being a minor one.
> 1.) I think it would be nice to map the authorship of Wiki edits to the
> corresponding LDAP user accounts - nice, but probably not mandatory, as
> the authorship is just sort of an 'attribute' to the Wiki edits.
> 2.) We should take care of assigning the existing Wiki user pages to
> their respective owners after we've introduced LDAP authentication to
> the Wiki.  I consider this issue as being a serious one because it's
> about real, precious content.  According to the tests I did on a
> separate Wiki instance, some of the user pages will just end up without
> any owner.  Some other user pages might get re-assigned to a different
> author, because some people registered their first name on the Wiki
> first, some other people registerd the same first name for the LDAP
> directory.
>
> Anyhow, we need to find a solution about what to do wrt. the user
> pages. Possible solutions could be:
>
> a) Ping every Wiki user, ask them to backup their own user pages until
> a date to be determined and purge every user page before we're
> migrating the Wiki over to LDAP authentication.  This leaves room for
> every user to re-establish their user page if preferred.
>
> b) Try to automate the mapping of user pages to the LDAP account names.
> Ask every Wiki user to enter their LDAP account name into a custom
> field at the Wiki login page, thus creating a list of Wiki-LDAP
> username pairings.  This would permit us (me) to replace every
> occurrence of the respective account names in the current OSGeo
> MediaWiki database.
>
> c) Have an additional entry field not only at the current Wiki login
> page but also at one of the OSGeo LDAP 'frontends', preferrably at the
> LDAP user profile edit page:
>
>    https://www2.osgeo.org/cgi-bin/auth/ldap_edit_user.py
>
> ....  where users are asked to enter the corresponding Wiki account
> name alongside with their LDAP account name.  The purpose of asking the
> users twice is to enable us (me) to do a consistency check, making sure
> nobody assigns some obscure Wiku user page to serious LDAP user
> accounts.
>
> Note, we (I) do _not_ need to establish any additional LDAP attribute,
> having a simple plain text list containing the respective account name
> pairs is entirely sufficient: One for the Wiki, one for LDAP.  Adding
> another entry field for the mentioned Python script should be rather
> easy, but I don't know how to properly add content to the Wiki login
> page.  I've tried adding some PHP code which looked reasonable to me,
> but ended up in having really strange formatting.
>
> Cheers,
> 	Martin.