$wgLDAPUseLocal and the template's 'useemail' property

Using LDAPAuthentication on our wiki but also allowing local users and logins (thus having set $wgLDAPUseLocal to true), we noticed that the email field was missing on the UserCreateForm. The email address being required to create a user, the form wouldn't submit successfully, thus preventing new users from signing up.

It took me a while to find that the modifyUITemplate() method was changing the template's properties. I thus suggest the following patch to LdapAuthentication.php in order to allow new users to sign up locally:

454   if ( $wgLDAPUseLocal ) {
455      // don't touch the useemail setting
456   } else {
457      $template->set( 'useemail', isset( $wgLDAPMailPassword[$_SESSION['wsDomain']] ) && $wgLDAPMailPassword[$_SESSION['wsDomain']] );
458   }

However, experimenting with this and another dirty workaround, such as setting $wgLDAPMailPassword in LocalSettings.php, I noticed that the value of $_SESSION['wsDomain'] in our case is 'invaliddomain'. (Thus requiring

$wgLDAPMailPassword = array(
  'invaliddomain' => true
  );

to achieve the same result as above.)

I did have "get_class($template) == 'UsercreateTemplate'" in the if statement above in the beginning until I realized that there's no email field at all at the login screen. Which brings me to the conclusion that this testing of $wgLDAPMailPassword[$_SESSION['wsDomain']] in modifyUITemplate() makes no sense at all, or does it?

Where it would make sense to test for some conditions would be at the point where a user would request to have a new, temporary password sent to him. Here, one would have to test either

whether the user is a local user and password retrieval is enabled at all
OR whether the user belongs to a domain, we have write access to ldap and LDAPMailPassword is set to true.

I can see that you cannot hide the "E-mail new password" button before the user has chosen a domain. But even with the above patch applied, the result of that action will still be "Login error Passwords cannot be changed", thus having done no harm at all.

Finally, I have noticed that the UserloginTemplate, on line 102, tests this before displaying the password-reset button:

if ( $this->data['useemail'] && $this->data['canreset'] ) {

So wouldn't this be more appropriate:

454      $template->set( 'canreset', isset( $wgLDAPMailPassword[$_SESSION['wsDomain']] ) && $wgLDAPMailPassword[$_SESSION['wsDomain']] );

circumventing all of the above problems? ;) (Though still requiring an exception for the retrieval of local user's passwords!)

Clausekwis‎

$wgLDAPUseLocal is kind of a hack that is meant for transitional purposes. I'm unlikely to add support for this, especially since it requires a really awkward configuration option.

Ryan lane‎

Hi,

I'd like to put everything together here so other users will benefit.

First of all, this post (my post, I mean!) does not care about $wgLDAPUseLocal.

What I'm interested here are these 2 Requirements:

ability to send a temporary password (reset password) in the login form;
ability to require obligatory email address in the register form.

The solution is:

1. Make sure you define $wgLDAPMailPassword like shown below:

$wgSitename = "MyWebsite"; // or whatever it is in reality
$wgLDAPMailPassword = array( $wgSitename => true, "invaliddomain" => true );

2. You will need to edit LdapAuthorization.php and modify method modifyUITemplate, like explained below:

The code was:

$template->set( 'usedomain', true );
$template->set( 'useemail',  false );

... which needs to be substituted by:

$template->set( 'usedomain', true );

global $wgLDAPMailPassword;
$template->set( 'useemail',  isset( $wgLDAPMailPassword[$_SESSION['wsDomain']] ) && $wgLDAPMailPassword[$_SESSION['wsDomain']] );
$template->set( 'canreset',  isset( $wgLDAPMailPassword[$_SESSION['wsDomain']] ) && $wgLDAPMailPassword[$_SESSION['wsDomain']] );

That's it. I hope it helps.

Thanks

Richard Gomes‎

Thanks Richard for your write-up!

Ryan: well the UseLocal option is essential for our use-case because we don't allow anonymous edits of pages. Thus we need everybody to register (and supply an email address) prior to being allowed to edit a page. But not every "editor" is a member of our organisation and therefore doesn't have an ldap account. So we need both back-ends. Other than that, I hope you can adjust what Richard repeated.