[patch]2 : mod_auth_ldap doesn't effectively use the cache with requireuser User1 User2 .. directives]
I have posted this patch proposal a week ago and since I got only one reply - how to
get round of the problem, and not any discussins about the problem itself or if my
proposal is reasonable or not for the module development,
I follow the instruction on the DEV page to repost it again.
The LDAP authentication has an important place, especially for big organizations with
a complex web environment. Since the mod_auth_ldap is an experimental module with
apache 2.0.x it it not part of some big distributions (an example - RH 8.0).
I think the mod_auth_ldap shoud be developed and supported as a standard apache modile.
--
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
---BeginMessage---
mod_auth_ldap doesn't effectively use the cache with require user User1
User2
.. directives
What the module does:
- 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
- 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 the authenticated user is the 100th one into the require user User1
User2
.. list we are going to have 99 LDAP requests sent and then the cache will
return the positive answer.
In practise we don't really use the cache here, and such kind of
require user
User1 User2 .. UserN directives can send hundreds of LDAP queries
each time we load a web page if the list is long enough! This seems to
be able
to disable some LDAP servers (at least I've experienced this with NW
one). The
real trouble is when we use products like DreamWeaver with WebDAV aceess to
the web site - when opens the site, it makes an inventory sending
PROPFIND to
every object on the site, in such a cases even two UserNames into the
list are
enough to flood the LDAP server.
What I propose to be changed:
- firstly, to check all words into the list only against the cache and
not send
LDAP queries
- secondly, if a match is not found then check all words into the list
sending LDAP queries to the server
- 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
(even more sophisticated idea could be to assemble a single OR
query and send
to the server)
this requires spitting the util_ldap_cache_compare:
util_ldap_cache_only_compare - checks for a cache match
util_ldap_server_only_compare - sends a request to the LDAP server
A proposed patch follows, I haven't compiled it with httpd2.0, but I
successfully applied a similar one with the auth_ldap module for apache 1.3.
Best Regards
Yavor Trapkov
--- mod_auth_ldap.c.org 2003-03-09 08:15:12.0 +0100
+++ mod_auth_ldap.c 2003-03-09 10:34:57.0 +0100
@@ -548,30 +548,35 @@
return sec-auth_authoritative? HTTP_UNAUTHORIZED :
DECLINED;
}
/*
- * First do a whole-line compare, in case it's something like
- * require user Babs Jensen
+ * Now break apart the line and compare each word on it
against the cache
*/
-result = util_ldap_cache_compare(r, ldc, sec-url, req-dn,
sec-attribute, t);
-switch(result) {
-case LDAP_COMPARE_TRUE: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise:
- require user: authorisation
successful, getpid());
-return OK;
-}
-default: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise: require
user:
- authorisation failed [%s][%s],
getpid(),
- ldc-reason, ldap_err2string(result));
+while (t[0]) {
+w = ap_getword_conf(r-pool, t);
+result = util_ldap_cache_only_compare(r, ldc, sec-url,
req-dn, sec-attribute, w);
+switch(result) {
+case LDAP_COMPARE_TRUE: {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
+ [%d] auth_ldap authorise:
+ require user: authorisation
successful, getpid());
+return OK;
+}
+
Re: [patch]2 : mod_auth_ldap doesn't effectively use the cache with require user User1 User2 .. directives]
it sould be it would be a good thing for apache -Kyle www.kyleserver.com - Original Message - From: Yavor Trapkov [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 16, 2003 12:28 AM Subject: [patch]2 : mod_auth_ldap doesn't effectively use the cache with require user User1 User2 .. directives] I have posted this patch proposal a week ago and since I got only one reply - how to get round of the problem, and not any discussins about the problem itself or if my proposal is reasonable or not for the module development, I follow the instruction on the DEV page to repost it again. The LDAP authentication has an important place, especially for big organizations with a complex web environment. Since the mod_auth_ldap is an experimental module with apache 2.0.x it it not part of some big distributions (an example - RH 8.0). I think the mod_auth_ldap shoud be developed and supported as a standard apache modile. -- 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
Re: [Win32] compiling Apache 2.1.0-dev: missing sslc.h
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: I tried -DHAVE_OPENSSL as compiler argument in the program settings with no success. Let me see if there are any other options. Hi, I found it :-) I have to set HAVE_OPENSSL=1 in the MS Visual C++ 6.0 compiler in the project setings under program arguments and of course saving the new project settings. Regards -- Juergen Heckel
mod_disk_cache problem
Title: Message hi, i know this may not be the appropriate place to post this, but i've search every corner of th web and found no answer... i'm using apache2.0.44 and linux 2.4.18-3smp #1.apache is connected to tomcat 4.1.18 via mod_jk2. I'm using apache standard cache configuration (loading mod_disk_cache). Yet for some reason, apache doesn't write anything to the CacheRoot dir. Just to make sure I didn't do anything wrong, I reinstalled apache again- this time on Win32, and using the exact same cache configuration apache cached all the urls, as it should have. Just to make sure it doesn't have to do with mod_jk2 and tomcat connectivity, I tried to see if apache caches static content (html files which are not served by tomcat) - and apache didn't cache those as well. any help would be greatly appreciated... Thanks, Ori. my httpd.conf (all is default, commented in the following): LoadModule cache_module modules/mod_cache.soLoadModule disk_cache_module modules/mod_disk_cache.so CacheRoot "/usr/local/apache2/proxy"CacheSize 5CacheGcInterval 4CacheMaxExpire 24CacheLastModifiedFactor 0.1CacheDefaultExpire 1CacheEnable disk /
Bug report for Apache httpd-1.3 [2003/03/16]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 7741|New|Nor|2002-04-04|some directives may be placed outside of proper co| | 7982|New|Maj|2002-04-11|mod_rewrite URL string empty when passed unicoded | | 8311|Opn|Nor|2002-04-19|error in PUT directive gives confusing error messa| | 8329|New|Nor|2002-04-20|mime_magic gives 500 and no error_log on Microsoft| | 8372|New|Nor|2002-04-22|Threadsaftey issue in Rewrite's cache [Win32/OS2/N| | 8508|New|Cri|2002-04-25|apxs generates incorrect LoadModule directive.| | 8683|New|Nor|2002-04-30|Insecure file permissions - make install | | 8849|New|Nor|2002-05-07|make install errors as root on NFS shares | | 8882|New|Enh|2002-05-07|[PATCH] mod_rewrite communicates with external rew| | 8889|New|Min|2002-05-07|Broken links in http://httpd.apache.org/dev/apidoc| | 9037|New|Min|2002-05-13|Slow performance when acessing an unresolved IP ad| | 9126|New|Blk|2002-05-15|68k-next-openstep v. 4.0 | | 9201|New|Maj|2002-05-17|Wrong REQUEST_URI with malformed HTTP queries | | 9427|New|Min|2002-05-26|bad negotiation when started with LANG=cs_CZ | | 9626|Opn|Nor|2002-06-05|ScriptAliasMatch fails with tilde in pattern | | 9678|New|Maj|2002-06-06|UTF-8 streams break some browsers | | 9726|New|Min|2002-06-09|Double quotes should be flagged as T_HTTP_TOKEN_ST| | 9894|New|Maj|2002-06-16|getline sub in support progs collides with existin| | |New|Nor|2002-06-19|Incorrect default manualdir value with layout.| |10025|New|Nor|2002-06-19|mod_rewrite broken in 1.3.26 ?| |10038|New|Min|2002-06-20|ab benchmaker hangs on 10K https URLs with keepali| |10052|New|Nor|2002-06-20|mod_proxy inserts a blank new line int headers whe| |10073|New|Maj|2002-06-20|upgrade from 1.3.24 to 1.3.26 breaks include direc| |10109|New|Maj|2002-06-21|problem running 1.3.26 and php on Solaris 7 / Spar| |10169|New|Nor|2002-06-24|Apache seg faults due to attempt to access out of | |10172|New|Maj|2002-06-24|Can't load libphp4.so with apache 1.3.26 + SSL 1.4| |10178|New|Maj|2002-06-24|Proxy server cuts off begining of buffer when spec| |10182|New|Nor|2002-06-24|Apache 1.3.26 and MOD_SO on OpenBSD 3.0 | |10195|New|Nor|2002-06-24|Configure script erroneously detects system Expat | |10199|New|Nor|2002-06-24|Configure can't handle directory names with unders| |10243|New|Maj|2002-06-26|CGI scripts not getting POST data | |10280|New|Nor|2002-06-27|notes / pnotes seem to no longer work in 1.3.27 | |10354|New|Nor|2002-06-30|ErrorDocument(.htaccess) fails when passed URL wit| |10470|New|Cri|2002-07-04|proxy module will not correctly serve mixed case f| |10666|New|Enh|2002-07-10|line-end comment error message missing file name | |10744|New|Nor|2002-07-12|suexec might fail to open log file| |10747|New|Maj|2002-07-12|ftp SIZE command and 'smart' ftp servers results i| |10760|New|Maj|2002-07-12|empty ftp directory listings from cached ftp direc| |10890|New|Cri|2002-07-17|if et locale is used, configure fails | |10939|New|Maj|2002-07-18|directory listing errors | |10961|Ass|Nor|2002-07-18|Redirect inside of Directory XYZ does not pass e| |11020|New|Maj|2002-07-21|APXS only recognise tests made by ./configure | |11053|New|Enh|2002-07-22|Apache 1.3.x won't log to a file larger than 2GB u| |11236|New|Min|2002-07-27|Possible Log exhaustion bug? | |11265|New|Blk|2002-07-29|mod_rewrite fails to encode special characters| |11291|New|Nor|2002-07-30|Cygwin script with long filename fails.Path separa| |11668|New|Maj|2002-08-13|mod proxy mod_rewite generate a invalid http res| |11765|New|Nor|2002-08-16|.apaci.install.tmp installs in existing httpd.conf| |11986|New|Nor|2002-08-23|Restart hangs when piping logs on rotation log pro| |11998|New|Maj|2002-08-23|mod_usertrack spot_cookie() will not allow Apache | |12074|New|Nor|2002-08-27|Compilation fails due to a _Isinf not found |
Re: [patch]2 : mod_auth_ldap doesn't effectively use the cache withrequire user User1 User2 .. directives]
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. - 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. - 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. - 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. Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight...
Re: Advanced Mass Hosting Module
Nathan Ollerenshaw wrote: What I have in mind is a module that fits in with our current LDAP based infrastructure. Currently, LDAP services our mail users, and I would like to see the Apache mass hosting configuration held in LDAP as well. In this way, we can just scale by adding more apache servers, mounting the shared docroot and pointing them to the LDAP server. I had this on the cards quite a while ago, but have not got around to actually finishing it off. The idea was a separate tool which would generate flat apache config files based on LDAP queries. The reason for the flat files was so the server could still restart and work even if the LDAP server was down. Kicking a server could be as simple as accessing a special URL, which recreates the flat config files and gracefully restarts the server. Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight...
Re: mod_disk_cache problem
Ori Tend wrote: I'm using apache standard cache configuration (loading mod_disk_cache). Yet for some reason, apache doesn't write anything to the CacheRoot dir. Are you sure Apache is allowed to write to your cache directory? Check the permissions and ownership. Does the cache directory exist? (Been bitten by this before). Regards, Graham -- - [EMAIL PROTECTED] There's a moon over Bourbon Street tonight...
Re: [patch]2 : mod_auth_ldap doesn't effectively use the cache withrequire user User1 User2 .. directives]
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
[patch] bogus support for pre-'make install' use of apxs
It looks like nobody has used apxs when httpd wasn't installed yet.
The following code in apxs is bogus:
#allow apxs to be run from the source tree, before installation
if ($0 =~ m:support/apxs$:) {
($httpd = $0) =~ s:support/apxs$::;
}
This takes a path /foo/support/apxs and assigns /foo (a dir!) to be $httpd.
unless (-x $httpd) {
error($httpd not found or not executable);
exit 1;
}
This doesn't fail, because the directory /foo indeed exists and it's
executable. Moreover the later check for mod_so, can't possibly work:
unless (grep /mod_so/, `. $envvars $httpd -l`) {
...
because $envvars is a path which doesn't exist, before httpd is installed.
Here is an attempt to fix that. Please verify that it works for you. You will
have to nuke (move) your installed httpd-2.0 in order to verify that it works.
Index: support/apxs.in
===
RCS file: /home/cvs/httpd-2.0/support/apxs.in,v
retrieving revision 1.53
diff -u -r1.53 apxs.in
--- support/apxs.in 19 Feb 2003 14:39:39 - 1.53
+++ support/apxs.in 17 Mar 2003 01:33:54 -
@@ -225,19 +225,23 @@
##
## Initial shared object support check
##
-my $httpd = get_vars(sbindir) . / . get_vars(progname);
+my($httpd, $envvars);
+#allow apxs to be run from the source tree, before installation
+if ($0 =~ m:support/apxs$:) {
+(my $base = $0) =~ s:support/apxs$::;
+$httpd = $base/ . get_vars(progname);
+$envvars = $base/support/envvars-std;
+} else {
+my $base = get_vars(sbindir);
+$httpd = $base/ . get_vars(progname);
+$envvars = $base/envvars;
+}
$httpd = eval qq($httpd);
$httpd = eval qq($httpd);
-my $envvars = get_vars(sbindir) . /envvars;
$envvars = eval qq($envvars);
$envvars = eval qq($envvars);
-#allow apxs to be run from the source tree, before installation
-if ($0 =~ m:support/apxs$:) {
-($httpd = $0) =~ s:support/apxs$::;
-}
-
-unless (-x $httpd) {
+unless (-f $httpd -x _) {
error($httpd not found or not executable);
exit 1;
}
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: discussion on fd leak problematic
At 04:36 PM 3/14/2003, Bjoern A. Zeeb wrote: this is a summary for further discussion on the fd leak problematic in httpd-2.0 and related apr (inherit) code. Again, thanks. This post focuses on the httpd aspects, presuming all of your issues in APR are addressed by that list, and all that httpd must do is to follow good design for the *expected* behavior of APR :-) Comments inline. The Problem has existed for a along time in httpd code but came not up before 2.0.40 because of another bug in apr which has been fixed before 2.0.40 release[3]. Yes - we've revised the exec/inherit code several times - each time 'improving' it but therefore impacting httpd's behavior. - From then on APR_IMPLEMENT_INHERIT_SET and APR_IMPLEMENT_INHERIT_UNSET worked the way they should but they had already been misused the wrong way for unknown reasons in httpd code. See cvs commits around the versions of diff in [4]. Correct, in part. Consider three models; -D ONE_PROCESS (-x) There is no parent - so we have no interest in propogating any handles except stdin/out/err for CGI and things such as pipe loggers. Unix Prefork/Worker Here the parent fork()s the child workers - without exec(). FD_CLOEXEC would work throughout httpd - even if a 3rd party module such as php were to call exec() or system() itself. That is a *huge* argument for apr to back our inherit_[un]set preference with FD_CLOEXEC. Same inherited handles as for -D ONE_PROCESS above, most will not need to be inherited. Win32 (others?) MPM Here we should be setting many handles as inherited in the parent process, which will call apr_proc_create to launch the child workers. There is a huge caviat here... the parent must pass those handles to the child through a currently undefined mechanism, and the child must receive those handles and then reset them with inherit_unset()! Now, where did my incorrect commits come in? I didn't recognize that, of course, fork() won't close any handles or invoke the cleanups. The child worker processes *are* the same 'process', as the parent, in a manner of speaking. HTTPD - - - - - - - - - - - - - - - - - - - - - because of the missuse of apr_file_inherit_set and not registered child cleanup_fn we have various fd leaks for pipes and logs. After my initial patch [1][10] Joe Orton came up with another patch to [EMAIL PROTECTED] My problem with this is: is it good enough to simply remove the apr_file_inherit_set() calls or explicitly use apr_file_inherit_unset() so that we can be sure that there is always a child cleanup_fn registered. First we must remove those calls, with a COMMENT to the effect that this code is needed to properly implement multiple child processes under non-fork()ing platforms. We don't respect those handles or provide the mechanics today - so we can comment out the code for today and re-enable, sometime in the near future, with the correct mechanics, respecting APR_HAS_FORK. In apr there still is the flag APR_FILE_NOCLEANUP that might prevent registering a child cleanup_fn as the deault for now is. This flag seems to be unused at the moment for open() calls. I don't think this affects httpd today - I believe that flag was for very, very persistent handles such as stdin/out/err Another thing I lately discovered after some discussion with Steve Grubb on lseek()ing on open file descriptors was that for me only error logs had been readable but not access logs. I think we do not need to open error_logs for reading. I agree... A fix for at least one place has been posted to [EMAIL PROTECTED] There might be other places where files are opened with more priviledges than needed. Please look at this. +1 to this patch. Agreed more research is required, and 3rd party authors should be sensitive to this issue. Bill
Re: Apache 2.1.0
At 06:54 PM 3/16/2003, Dave wrote: When are we going to start seeing httpd 2.1.x releases? httpd 2.0.x releases were coming out about two years before a GA release. What is the plan for 2.1.x functionality? We will have no 2.1.x-gold releases, the 2.1-dev tree is (by definition) -beta. So we should get busting on a 2.1.0-beta pretty soon here :-) But don't look for it before we've let 2.0.45 fly this week, and get a few days feedback about any possible regressions (none, we hope!) :-) We should still follow the -alpha then -beta convention, where we first identify the release as -alpha just to check that the packaging and such are goodness before the majority of the community grabs the package. Just interested! I would like to use mod_dav_lock. Cool! We need early adopters :-) We hope that most module authors will begin working with the 2.1-dev tree long before 2.1 is released, especially requesting changes that we can't make to 2.0 without breaking compatibility, but that would greatly simplify, speed up or otherwise improve their modules. It will be strongly 'supported' - in the sense that we want to lick bugs. But it will be a moving target - we *want* to break the API in any way that will benefit the httpd 2.2 server once it is released. Really, 2.2.0-gold will be the first 'release' of the 2.1-dev efforts. One, we expect the changes will be much less substantial than 1.3-2.0 were. And 2.1-dev isn't and 2.2 won't be binary compatible with 2.0 modules. But if we've accomplished our goals, all 2.2 releases will be binary compatible with one another (at least forward compatible, e.g. 2.2.3 module that uses a brand new feature should work with 2.2.3 or later, and a module authored to the 2.2.0 API should be compatible with all 2.2 releases.) Bill
Antw: Re: [patch]2 : mod_auth_ldap doesn't effectively use thecache withrequire user User1 User2 .. dir
[EMAIL PROTECTED] 16.03.2003 21:45:12 Graham Leggett [EMAIL PROTECTED] wrote: 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. I'm against yet another option, because we can't guarantee correct behaviour if the quotes are turned off. Better when we find a in the line, use those as quotes. If no are found, then use the blanks as separarators. (And this automatically disallows usernames with blanks in them.) BTW, how the other apache authentication modules treat this situation? Good question 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. The only advantage a negative caching would provide is (slightly) a better handling of DOS attacks. Of course a DOS attack is still possible when requestings user1, user2 user9 Of course a negative cache should have a short cache lifetime. 3-5 minutes or so. André aarboard ag internet - networks - screenprint design - multimedia Egliweg 10 - Postfach 214 - CH-2560 Nidau (Switzerland) Phone +41 32 332 9714 - Fax +41 32 332 9715 www.aarboard.ch - [EMAIL PROTECTED]
