search

noushadali / pwm

Automatically exported from code.google.com/p/pwm
0 stars 0 forks source link

Patch for /trunk/pwm/servlet/src/password/pwm/Validator.java #417

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Before we can call compareStringAttribute we need to make sure that the EntryDN 
does have a value for that attribute. At least eDirectory will throw an LDAP 
error (603) when doing a compare on an EntryDN without a value for that 
attribute.

See my testresults for LDAP compare at 
https://forums.netiq.com/showthread.php?48106-LDAP-compare-not-working-as-docume
nted-in-SDK

I've analyzed the source code of com.novell.ldap.LDAPConnection and it seems 
that we need to check for the attribute presence ourself.

Original issue reported on code.google.com by sebastia...@gmail.com on 2 Jul 2013 at 12:10

Attachments:

GoogleCodeExporter commented 9 years ago 
After rereading my report I think I need to elaborate on this bug by a use case:

1. Let's say we have User A which is going to update his/ her profile.
2. The Update Profile form has two editable fields which both have a unique 
requirement
3. For now call these atttributes: attr1 and attr2.
4. User A fills in value 1 for attr1 and value 2 for attr2.
5. The user gets a "PWM unknown error" after the XHR update.

The reason:
There is a second user in the LDAP directory with a value 1 for attr1, but no 
value for attr2. The current codebase does a LDAP compare on the values of the 
DN's in the search results on all attr values of User A, without checking in 
advance if those attes are set on the DN's within the search result.

At least with eDirectory this is a problem (but probably with other LDAP 
directories that implemented RFC 4511), because this leads to a LDAP error with 
root cause a NDS error:

LDAP error: No such attribute (16)
Additional info: NDS error: no such attribute (-603)

In summary PWM should always check if the target User has a value set for a 
given attr, before doing an actual LDAP compare on that same attr. The patch 
fixes this issue.

Original comment by sebastia...@gmail.com on 25 Aug 2013 at 6:22

GoogleCodeExporter commented 9 years ago 
Will investigate after 1.7.0, thanks for the updated description, that helps.

Original comment by jrivard on 26 Aug 2013 at 6:59