Graham Leggett <[EMAIL PROTECTED]> wrote: >Yavor Trapkov wrote: > >> - firstly, it checks if the whole string "User1 User2 .." matches the CN >> of the >> authenticated user and as this is a very rear situation it almost always >> fails so each time we request a page, the WEB server sends a LDAP >> query as this >> is never cached as a negative result > >We have to check this case first, otherwise we could have false positives. > >A better workaround for this is to insist that all the tokens in the >require list be surrounded with "'s if there are spaces involved in the >search pattern. Then we can drop the whole line search entirely. >
You are right, we can have false positives, i.e. positive match for "Firstname" when we want to look for "Firstname Secondname", but this logic can be applied in reverse order, i.e. positive match for "Firstname Secondname" when we want to look for "Firstname". Then your idea to use "'s and have only one check is probably a solution or we can have an extra option to specify how this "require user User1 User2 .." to be interpreted - as a single value or as a list of values. BTW, how the other apache authentication modules treat this situation? >> - secondly, there is a loop that checks if every single entry in the list >> matches the CN of the authenticated user >> = it checks if this is a cached positive result >> = and if not it sends a LDAP query >> = this happens until it finds a match or the list finishes > >If you have a need for more than one user on a require user line, then >you really should be using LDAP groups. LDAP groups are far more >managable anyway. Directives as "require user User1 User2 .." are very commonly used with apache (and very convenient) and in this style, I think, many users might prefer to use that with LDAP authentication as well. > >> - firstly, to check all words into the list only against the cache and >> not send >> LDAP queries > >What you are asking for is negative caching, which I am not 100% >comfortable with. If a login fails due to some error (eg wrong >password), and the error is subsequently fixed in the directory, the >next time the query is tried with the correct password the comparison >will fail until the negative cache has timed out. This will not be >immediately obvious to the user, and will probably be reported as a bug. > The problem here is that we never use the cache with such a directive, like the module works now, and if it's used (wrongly or not), it can generate many requests to the LDAP server. If first all values are checked against the cache and then if we don't find a match we go to the LDAP - this will make the cache used properly - no ldap requests sent if we have cached the positive result, the negative results are not cached anyway. I don't see negative cacheing. >> - at last, to check for the whole string "user1 user2 .." as this is very >> rear case and in almost all cases gives a negative result > >It is not a rare case - if you match against cn (as iPlant directory >server does by default) you will almost always use this case. > "Firstname Secondname" is probably not so commonly used username (having " ") >Regards, >Graham >-- >----------------------------------------- >[EMAIL PROTECTED] "There's a moon > over Bourbon Street > tonight..." > > Regards -- Yavor Trapkov __________________________________________________________________ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
