Item11409: HtpasswdUser issues when shared between multiple Foswiki instances
Priority: Normal
Current State: Closed
Released In: 1.1.5
Target Release: patch
Applies To: Engine
Component: HtPasswdUser
Branches: Release01x01 trunk
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