17487 Posts in 4473 Topics by 1978 members
|Go to End||Next >|
15 April 2008 at 12:14pm
I noticed that if I put the wrong username and password in it does come up with "Authentication failed" but the correct username and password still just brings up http://localhost:3000/Security/?executeForm=LoginForm
16 April 2008 at 8:11pm
LDAP authentication goes through a few phases:
1) Find the user DN based on the given ID
2) Bind as this user
3) Lookup user details.
Your previous post leads me to believ that 1) is working well. To find out if 2) is working, you could try to enter a correct user id, with the wrong password. If this results in a blank screen, then this is where the problem is. If you get authentication failed, then the problem is in 3) or in the auth_external code beyond.
Could you give this a try?
17 April 2008 at 11:08am
As you suggested, I entered a correct user id, with the wrong password and this results in a blank screen...
18 April 2008 at 2:53am
Find "public function Authenticate"
1) Add a double forward slash before the first instance of "restore_error_handler" and put // before it
Try good account with right and wrong pass. And report what happens then undo this change
2) Before "$bind = @ldap_bind(self::$ds, $dn, $external_passwd)" add
"$bind =ldap_unbind(self::$ds);" (remember the ; at the end of the line)
2a) Remove the @ before ldap_bind
Try good account with right and wrong pass. And report what happens then undo this change. If it works now, stop here.
3) Add "print_r($dn); exit;" before @ldap_bind and try to log on.
The logon will certainly fail now, but you can see if the DN is ok, since is should be shown in the browser window.
Undo the change.
18 April 2008 at 11:07am
1) With or without // a good account with right and wrong password returns a blank page.
Should I leave the // there?
2) I changed it to:
$success = false; //Initialize the result of the authentication
$bind = ldap_unbind(self::$ds);
$bind = ldap_bind(self::$ds, $dn, $external_passwd);
But a good account with right and wrong password returns a blank page.
Then I changed it back but still nothing.
Should I be doing more than saving it, doing a http://localhost:3000/db/build?flush=1 and restarting lighttpd after each change?
3) Again the same result
My primary browser is Firefox 3 Beta 5, but I've tried it in IE7 too. Maybe it isn't even getting this far through the code??
18 April 2008 at 6:32pm
1) Undo the //
We could still be at the right place. This behavior could be explained if no DN was returned. So lets focus on the DN searching.
Between code changes you certainly need not restart the http server. Flushing the cache should not be needed as we are not changing templates, but it may be wise to do it anyway.
We are now going to put some checkpoints in
"private function findDN($source, $ldapattribute)"
There are 2 instances of the text
"$result = @ldap_get_entries(self::$ds, $search);"
Put "echo 'hello'; echo $filter; print_r($result); exit;"
After both. Now try to log on with all variations. You should at least get back hello. Hopefully with some more information.
You could also try to verify the workings of the module by adding another authentication source of type SILVERSTRIPE. (You'll have to add a user ID to the user record)
Don't know is the PHP install on windows uses modules, but you could check for the file php_ldap.dll on your system and/or php_ldap in your php config files (php.ini and such)
19 April 2008 at 10:53am
It would be handy to get some unit tests developed for the external_authenticator module. We would then be able to run these tests against new versions of SilverStripe, to ensure that upgrades don't break your module!
Of course, to really work properly you need to be able to run the tests without having an LDAP server to connect to.
One way of doing this is to make a class LDAP, that basically contains methods that call PHP's ldap_XXX methods.
When constructing the LDAP_Authenticator, have a constructor argument that can specify which of these LDAP objects to use. Setting the default to being new LDAP(), would be fine, or you can use this to specify the LDAP server that you would like to connect to.
You can then create a test version of the LDAP object, either by coding it up explicitly, or by using mock objects: http://www.phpunit.de/pocket_guide/3.0/en/mock-objects.html
This TestLDAP object would be set up to return fixed values for the various LDAP calls. You could potentially create variant versions of this to test situations such as failing to connect to the LDAP server.
The SecurityTest class on the govtsecurity branch provides a useful example of how to test a log-in form:
20 April 2008 at 1:26am
Unit tests was planned for 0.3. I'm trying to allocate some time to do it ;-)
As for running the test without LDAP server; We can simulate openldap behavior, but I don't know how e.g. AD behaves, since it is not fully LDAP compliant (or else we wouldn't have this problem).
But thanks for the information pointers
|Go to Top||Next >|