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
