aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
blob: e4a411780aa6757e04887eb3076064fbe4e1e338 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[[!tag wishlist]]

Ikiwiki is static, so access control for viewing the wiki must be
implemented on the web server side. Managing wiki users and access
together, we can currently

* use [[httpauth|plugins/httpauth/]], but some [[passwordauth|plugins/passwordauth]] functionnality [[is missing|todo/httpauth_feature_parity_with_passwordauth/]];
* use [[passwordauth|plugins/passwordauth]] plus [[an Apache `mod_perl` authentication mechanism|plugins/passwordauth/discussion/]], but this is Apache-centric and enabling `mod_perl` just for auth seems overkill.

Moreover, when ikiwiki is just a part of a wider web project, we may want
to use the same userdb for the other parts of this project.

I think an ikiwiki plugin which would (re)generate an htpasswd version of
the user/passwd base (better, two htpasswd files, one with only the wiki
admins and one with everyone) each time an user is added or modified would
solve this problem:

* access control can be managed from the web server
* user management is handled by the passwordauth plugin
* htpasswd format is understood by various servers (Apache, lighttpd, nginx, ...) and languages commonly used for web development (perl, python, ruby)
* htpasswd files can be mirrored on other machines when the web site is distributed

-- [[nil]] 

> I think this is a good idea. Although unless the password hashes that
> are stored in the userdb are compatible with htpasswd hashes, 
> the htpasswd hashes will need to be stored in the userdb too. Then
> any userdb change can just regenerate the htpasswd file, dumping out
> the right kind of hashes. --[[Joey]]