Looking over Foswiki::Users::HtPasswdUser the file lock is written to the working directory. This creates an exposure on Foswiki.org, where we allow password maintenance from both foswiki.org and trunk.foswiki.org. Each can lock the same file simultaneously.

Also, now that foswiki.org is running fcgi, password changes made by trunk won't be recognized by Foswiki.org until the fcgi processes restart.

• The lock file should probably be written to the same directory as the .htpasswd file so that multiple Foswiki instances use the same lock.
• The file timestamp should be tested before trusting the cached passwords. However this might be a configuration option since sharing the file externally is probably an unusual configuration and stat is costly.

-- GeorgeClark - 06 Jan 2012

Babar pointed out that not all installations will be able to create files in the directory containing .htpasswd, so this needs to be a configurable location.

Also in reviewing this a bit more, do we need to test the file timestamp anytime fcgi or fastcgi is used. I think each foswiki.fcgi handler gets it's own copy of the password cache.

-- GeorgeClark - 07 Jan 2012

AFAICT there's no point (unless you make rather more sweeping changes). As I recall, the password manager is not a glob object - it is instantiated from the user manager, which is in turn instantiated from the session. Since the session is cleared down for each request, the usefulness of this "cache" is questionable, and checking file dates for it even more so.

There are (at least) two tactics that would improve htpasswd performance; the first is to hash the user id to hit one of a number of different .htpasswd files, to reduce the load time for the PW file. The second would be to make a real cache which persisted over sessions. If the latter tactic were implemented, your recent change against this task would make sense.

-- CrawfordCurrie - 08 Jan 2012

See Tasks.Item11436 which makes the password cache global.

-- GeorgeClark - 11 Jan 2012