mrnipper

I’m actually waiting on the other ticket to hit 3.4 (hopefully) because my site admins are annoyed with not being able to simply add users and skip the confirmation step entirely. In an academic setting, and using LDAP authentication, the confirmation is entirely unnecessary and only serves to confuse our users.

This problem I mention is more of an annoyance for our site admins, because it’s always possible for a user to change their email address. But their LDAP based user name will never change in our system and it’s the one thing that can always be considered authoritative.

I guess I can play around with the code and submit a patch. I looked around a bit in Trac for anything about this. Given the existence of the aforementioned request for enhancement, I felt like this should probably be handled the same way. Given sufficient privilege (and site admin I think would qualify), either an email address or a user name can be used to add an existing network user to your site.

That doesn’t make any sense. There are two fields normally, one for adding new users and one for existing users. When adding an existing user as a super admin, you have the option of using an email or a user name. When adding as a site admin, you only can use an email. We also have the option to add users disabled at the network level, so site admins don’t see the add new field at all anyway.

And once the person has been added, the site admin is going to see their user name anyway, so it doesn’t seem like a potential security or information leak necessarily to let them add by user name just like a super admin can.

I can take out the check for is_super_admin and the get_user_by would work just as well for a site admin as a super admin, no? The question is, does that present a security risk of some kind that I’m not seeing?

You might take a look at the patch I posted about recently which fixes this plugin to work with multisite and single site. It allows you to specify the LDAP settings globally from the network side of things, assuming that you want all of your sites to point at a single LDAP instance.

Here.

I should also mention that you need to be running at least version 3 of WordPress with this patch. It uses newer functions introduced with version 3 which work regardless of whether single or multi site is being used.