On 26 May 2009, at 15:56, Guillaume Rousse wrote:
Chris Ridd a écrit :
On 26 May 2009, at 14:42, Guillaume Rousse wrote:
Hello list.
Some time ago, I had an issue with set_password() not handling
controls:
http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html
It was fixed in perl-ldap 0.38.
I also opened an ITS in openldap, because apparently password
modify exop was not returning ppolicy control correctly:
http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html
It was fixed in openldap 2.4.12
However, it still doesn't work. The following test case shows than
the value returned by $response-
>control( LDAP_CONTROL_PASSWORDPOLICY ) is always '1', instead of
an instance of Net::LDAP::Control::PasswordPolicy class.
Can you give us BER dumps of the exop itself and the response?
Is there any other way beyond network capture directly ?
It is the only way to prove what's being sent/returned is buggy (or
not). If the data being sent/returned is good, we look to see where
the perl code's gone wrong, if it is bad there's not much we can do.
Use the debug method on your Net::LDAP object to get the output, maybe
xx out the sensitive hex and ASCII data.
Before I reopen the ITS, I'd like to be sure my perl code is
correct first. In particular, is this normal to send a control
object in the request, and to get another distinct control object
from the response ?
Not sure what you mean by "distinct" but it is how the password
policy draft is designed. Paged results is a little similar.
distinct here means calling $result->control(), instead of directly
using the control created earlier with
Net::LDAP::Control::PasswordPolicy->new(), and passed to the
set_passwd() operation.
I see what you mean. In the case of ppolicy it is normal; the server
sends information to you in an LDAP control inside the response
(password good/bad/too short/etc), and that's what you're extracting.
In paged results the server sends you some kind of cookie which you
resend to continue the search. They're both normal techniques then,
but uncommon ones.
Cheers,
Chris
