Posted 2 years ago #
After getting in touch in and getting "approval" from its author, I'm attempting to fork off and revive wpLDAP and would like the code to be peer reviewed by other developers before I release my version.
Dev version is in my SVN repo at:
http://labs.tekartist.org/wordpress/svn/branches/dev/plugins/wpDirAuth/
Please add feedback here.
Thanks for any help I can get. :)
Posted 2 years ago #
Oh wow, don't everybody post at once. ;p
(note: I'm stephdau, posted from wrong account...)
Posted 2 years ago #
I'm willing to help you test out authentication via LDAPs, but I'm brand new to WordPress (downloaded this afternoon). I put wpDirAuth.php in the wp-content/plugins directory and according to the wp-admin/plugins.php page, it's activated. How do I set it up with the proper information for my LDAPs server?
Posted 2 years ago #
OK, I figure out that the secret is to deactivate the plugin and then look for the setup menu in options. Do I need to do anything in wp-config.php to enable this?
Posted 2 years ago #
Hi there,
First, thanks for giving it a shot. :)
I haven't had time to write the readme yet, so here it goes:
Installation:
- create as follow [wordpress_root]/wp-content/plugins/wpDirAuth/
- drop wpDirAuth.php in the latter directory.
- go to http://[wordpress_install]/wp-admin/plugins.php and activate the plugin
- go to http://[wordpress_install]/wp-admin/options-general.php where you should now see a menu entitled "Directory Auth."
- click it and it should take you to the plugin admin screen, most likely located at http://[wordpress_install]/wp-admin/options-general.php?page=wpDirAuth.php
I've been debating having the menu under the plugin section instead, but also being new to WP, I'm not sure if there are backward compatibility issues and if having the admin tool in the Options section is better. To be debated. :)
In case it comes up, one of the reasons that I'm not using OO on this one is primarily due to the limitations of OO in PHP4, which WP still supports (probably at least for a few more months, until php.net drops their own support of php4 [sched. for around 2008-01-01]).
Let me know how it goes.
Posted 2 years ago #
I now added an initial readme file in the subversion repository: http://labs.tekartist.org/wordpress/svn/branches/dev/plugins/wpDirAuth/readme.txt
Based on the standard WordPress readme format: http://codex.wordpress.org/Writing_a_Plugin#Readme_File
Posted 2 years ago #
I also just launched a plugin hosting request to http://dev.wp-plugins.org/ so we can get access to svn and Trac project management tools there.
Posted 2 years ago #
Thanks for the information. I misunderstood the plugins form, I thought that it was showing me the state of the plugin "Activate", when it was really showing me a command button. I got the plugin activated. The login window is slightly different (but doesn't have the text that I keyed into the "branding" section of the plugin setup.) It also recycles almost immediately and doesn't let me log in. The is a new hyperlink at the bottom of the page "please access the encrypted version of this page" which seems to have a zero refresh: <meta http-equiv="refresh" content="0;url=" /><p>Please access the <a href="">encrypted version</a> of this page.</p></form></div></html> but no url is in the link. I tried to change the page to use https:// but I get the same constant reload. https is set up on the web server and works just fine. Is there some other plugin or configuration setting that I missed?
Posted 2 years ago #
I was able to get a little farther by disabling the "Require SSL Login" settings in the wordpress settings section of the plugin options of wpDirAuth. I now get the proper text label in the login box. I haven't gotten a successful login through the LDAPs yet, but that could be a problem with our setup and I'll check into it.
I evaluated a similar plugin: admin-ssl that does a https for logins and the admin pages. This plugin works OK for the SSL logins on my web server.
Posted 2 years ago #
I believe that I figured out the problem with the login credentials failing. With our LDAP, in order to bind with a password, the ldap_bind "userid" (i.e second argument) needs to be the full dn, not just the userid. What I think needs to happen is to do an anonymous bind, use it to search for and return the dn, then use the dn as the second argument in the ldap_bind call with the password.
Posted 2 years ago #
Are you by any chance using OpenLDAP?
I wonder if an update to the ldap_bind call similar to the one linked to below would help:
http://ashay.org/?page_id=133#comment-558
I'll see if it works in AD.
Posted 2 years ago #
I glanced at the post. I am using OpenLDAP (on Linux). The problem is for our LDAP is that the DNs are not the same for all users. We also have an "l=" parameter (location??) that will differ depending on the user. Mine is l=US others have l=GB, etc. The users wouldn't necessarily know about this parameter. I wrote a simple php routine to test out ldaps and I couldn't bind with password without the l=US in my DN. I'll do some more experimenting tomorrow when I get into work.
Posted 2 years ago #
The snag I'm hitting with implementing the solution you suggested is that on my side, my dir server won't let me search without binding... The old chicken and egg thing. :)
Soooo, what I did was to try and couple both approaches.
Since there was already an anonymous bind being performed in the connection pool loop, I'm trying an anonymous search on success, trying to retrieve the targeted user's full dn.
If the profile is located, user binding is performed with the full dn, or we try the sent username instead.
See lines 363-368 in the updated version available in SVN.
Is that solving it for you?
On another note, could you post details about your setup?
OS, dir server type, ldap configs with "Blah Corp" instead of your company's info where it matters, etc?
PS: I'm in Montreal, and can only devote time to this in the evening, hence my posting timeframe. :)
Posted 2 years ago #
Oh, hadn't refreshed the page before posting my last comment and I missed your added info.
The code I added will only really help if the username we search for anonymously matches the unique identifier defined in the account filter. This actually translates to sentUsername + accountSuffix if setup in the wpDirAuth prefs [optional].
Here's an example which might help you with part involving locating the user's profile, whether for dn pre-mapping (added code), or binding:
In what I've seen in other php/ldap related code, people seem to default the field on which we try to locate the profile with to samAccountName (hence the default in wpDirAuth), which seems to be assumed to be the same value as the username used to bind with.
In my context, the samAccount is in one form, but the username used to bind (first.last@myDomaincontroller, not full dn) with simple auth actually matches a field named userPrincipalName.
So in my setup, I expect users to enter first.last@myDomainController, leave the Account Suffix pref empty (since we have multiple ones), and set my Account Filter to userPrincipalName.
As an aside, I'm realizing that I need to make sure the added code didn't open a hole if the anonymous search returns more than one entry, since we ultimately default to entry[0] when returning to wp_login.
Posted 2 years ago #
SVN Rev. #308
Added extra security check to make sure only one account is returned during the profile search in wpDirAuth_auth, before returning to wp_login. Better safe than sorry.
Posted 2 years ago #
SVN Rev. #309
Extra error checking and handling tweaks + cleaned up error messages format for easier future localization.
Posted 2 years ago #
Just wanted to say thank you!
I am new to openLDAP, but your PlugIn works perfect!
I didn't take it do a online site, but i sure will do in near future
Thx!
Koelly
Posted 2 years ago #
@koelly: thanks for the quick note. Glad it can be of use. :)
Posted 2 years ago #
Hi,
Update: I looked at the changes and I think that they'll work OK. There is something odd in my php web installation that I'm working on. I wrote a php routine the does ldap and ldaps OK from command line but only ldap, (not ldaps) works when I run it as a web page in apache. Once I get that straightened out, I'll try the module again.
Posted 2 years ago #
@tabeverly: good luck. Let me know how it goes. :)
Posted 2 years ago #
While wpDirAuth is being peer reviewed, I released another plugin I use on my site. :)
Posted 2 years ago #
@tabeverly: I didn;t offer before because I don't know your level of sysadmin expertize, but feel free to let me know if you need help troubleshooting the CLI v. http you're having with PHP.
On another note, I've published the wpDirAuth code doc, if anyone is interested: http://labs.tekartist.org/wordpress/wpdirauth/phpdocs/
Posted 2 years ago #
@stephdau: There was an odd ball permissions problem with my certificate authority (CA) file in apache. It looks like PHP is using the apache variable LDAPTrustedCA to pick up the CA and the CLI was using the ldap.conf files. In any case, http/PHP/LDAPs is now working on my system and I'm trying wpDirAuth again.
Posted 2 years ago #
@stephdau: Update. Login via LDAPv3 server now works great! The only thing that isn't working for me is the option to "Require SSL Login" (Options/Directory Authentication Options/Wordpress Settings/Require SSL Login). When I enable it the Login page constantly refreshes and the url parameter in the meta tag is blank :<meta http-equiv="refresh" content="0;url=" /><p>Please access the encrypted version of this page.</p>. It could be something strange on my server (again.) I'll keep looking.....
Posted 2 years ago #
@tabeverly: Thanks for your continued support. :)
All the "Require SSL login" should be doing is to scan if the current login screen URL starts https, and redirect to the same URL under https if not. I haven't tested it too much but it seemed to work in my tests.
See the first few line of wpDirAuth_login_form_extra(). A potential issue would be if the built-in $_SERVER["SCRIPT_URI"] PHP pre-defined variable is somehow not available in your instance. Could you edit wpDirAuth.php and add something like the following code bits around line 438 of the current dev version (right after if(get_option("dirAuthRequireSsl")...) and tell me what the result is?
var_dump($_SERVER["SCRIPT_URI"]); exit;
It might just be a matter of using another PHP var that would always contain the accessed protocol.
Posted 2 years ago #
@stephdau: I was just going to write in and tell you the $_SERVER["SCRIPT_URI"] isn't set for my php via apache.
I was able to cobble this up from various sources. It seems to work for me:
function wpDirAuth_login_form_extra()
{
if(get_option("dirAuthEnable")){
$self_url = sprintf('http%s://%s%s',
(isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on' ? 's' : ''),
$_SERVER['HTTP_HOST'],
$_SERVER['REQUEST_URI']);
//if(get_option("dirAuthRequireSsl") && (!preg_match('|^https|',$_SERVER["SCRIPT_URI"]))){
if(get_option("dirAuthRequireSsl") && (!preg_match('|^https|',$self_url))){
$location = str_replace('http://','https://',$self_url);
$refreshMeta = '<meta http-equiv="refresh" content="0;url='.$location.'" />';
$refreshMsg = 'Please access the <a href="'.$location.'">encrypted version</a> of this page.';
if(@ob_end_clean()){
//$location = str_replace('http://','https://',$_SERVER["SCRIPT_URI"]);
if( (@header('Location:'.$location)) == false){
echo '<html><head>'.$refreshMeta.'</head>'
. '<body>'.$refreshMsg.'</body></html>';
}Please excuse the sloppy coding, it's my first attempt at php programming.
Also, I moved the $location line up to just under the get_option("dirAuthRequireSsl") line so that it's set for the str_replace. As you say, there may be a variable set that has the value of my calculated $self_url and I'll keep looking.
Posted 2 years ago #
@tabeverly: Ah, excellent.
re: quality: Trust me, I've seen worst PHP coming out of much more experienced developers (yes, me included :).
I might just use your patch, but I'll first take a look at an ultra portable PHP project I worked on a few years ago (netjuke) because I know I've had to deal with something like that in there(some vars are not available on Windows, etc). The latter would ahve the benefit to have been tested on a slew of platforms and to insure we end up with the best support possible. Having been coding PHP for *nix exclusively in the last few years, it escaped me in this one. :)
I'll post later tonight.
Posted 2 years ago #
@tabeverly: I have modified the code with your patch (only slightly tweaked), but I forgot to commit it before starting on something else (addition of optional TOS agreement step). Ooops.
I'll commit the whole thing when I'm done with it tomorrow, and I think it might just be time to start packaging 1.0rc1, which I will start running on a pilot project WP install in my institution. The latter is in production, but less high visibility than others soon to come.
On a separate note, feel free to drop me an email at labs [at] tekartist [dot] org with whatever references you want listed in the credit files. :)
But for now, it's 1AM, time to snooze. Ciao.
Posted 2 years ago #
I have now commited the changes:
See:
I'll work on the readme and credits file tonight, as well as on packaging the upcoming 1.0rc1. Maybe it'll just be 1.0, since I'm about to roll it into production at my institution anyway.
Posted 2 years ago #
I've done an initial code review before installing the software, and it looks good.
Please see this copy editing patch that corrects a few English usage and punctuation problems.
-Richard Bullington-McGuire
This topic has been closed to new replies.
