How to password protect your wiki !!5!! >How to password protect your wiki !!6!! !!7!! You can specify what authentication to be used based on a regular expression match against the url used to access the page. !!8!! !!9!! Open !!10!! !!11!! in your wiki directory. Un-comment and edit the authenticators section and edit the array. The format is [ [ first regexp to match against title, authenticator to use ], [ second regexp to match against title, authenticator to use ] ... ]. For example: !!12!! !!13!! >No authentication !!14!! !!15!! The following matches against all the standard ‘non editing commands’ and doesn’t ask for any authentication: !!16!! !!17!! !!18!! !!19!! >No uploads !!20!! !!21!! The following doesn’t permit any file or picture uploads: !!22!! !!23!! !!24!! !!25!! >Site wide password !!26!! !!27!! The following asks for a site wide password to edit or save changes to the home page: !!28!! !!29!! !!30!! !!31!! >Per-user passwords !!32!! !!33!! The following uses the standard WEBrick authentication system on any page whose name starts with private. The standard WEBrick authentication uses a database of usernames and passwords. See !!34!! for details. !!35!! !!36!! !!37!! !!38!! The following is the default. For any page it just asks for a username, but the password can be left blank. !!39!! !!40!! !!41!! BasicAuth isn’t very secure as it transfers passwords over plaintext. If you can cope with some incompatability with very old browsers, DigestAuth is more secure. To implement DigestAuth: !!42!! > !!43!! run this command: !!44!! !!45!! and enter your password. On gentoo, the full path is !!46!! !!47!! !!48!! !!49!! Add this line into start.rb, inside the authenticators= block: !!50!! !!51!! !!52!! !!53!! !!54!! >Multiple authentication systems !!55!! !!56!! To further-complicate your login woes, there is a nifty trick you can pull with the way Soks does its authentications. Because it creates a separate instance of the authenticator for each regexp, you can stack ‘em :) Say you want to restrict viewing to those who have an account, but you don’t want everyone to be able to edit. The first step is to create two htdigest files. !!1!! . One will have those who can read, the other those who can write. When you make these files, ensure that the realms are identical !!2!! . Now assign the htdigest.write to the (edit|save) bits, and the htdigest.read to the (view|print|etc) bits. The annoying bit is that users who can edit need to be added to both files, but it makes up for it by users not having to login again when they want to edit. !!57!! !!58!! !!59!! >Suggestions / The future !!60!! !!61!! Is there any means to changing the authentication on the fly like how the editable sidebar page” works? (Have a “master” page that is access controlled, on which one would put other page links that would then become access controlled.) Bil !!62!! !!63!! Can someone point me to an example (or outline the steps) to having the user names checked for validity by an LDAP server ? (Note: I asked a similar question on the Webricken mailing list.) Bil !!64!! !!65!! Not used LDAP myself, but the example at http://dataspill.org/posts/show/4 seems to show how one might communicate with the LDAP server to check valididty. This would need to be inserted into a WEBrick authenticator. If you just duplicate the code of an existing WEBrick authenticator (e.g. 1.8/webrick/httpauth/basicath.rb) you should be able to do a few tweaks to the authenticate method to get what you want. tamc2 !!66!! !!67!! Not understanding much ruby, it seems like the instructions above are out-of-date. My !!68!! !!69!! authenticators stuff doesn’t look like an array but instead looks like !!70!! !!71!! !!72!! !!73!! and I don’t think they were commented out in the first place. What is the default action, if no authentication is specified? Also, what does “begins with private” mean... the page name, or the directory in which it is stored? I’d like to use per-user authentication in part of my website for viewing !!3!! . !!4!! !!74!! !!75!! bjax (Jan 5, 2006) !!76!! !!77!! Tag: Include this page in the distribution !!78!!
Edit this page or watch for changes using RSS.