The Über private wiki

Scenario 1: .htpasswd (single dummy account)

Currently using an .htpasswd file, an admin can hardcode a username/password that every wiki user must know before getting in. This would work except that the credentials get saved for the domain/path by the browser and are sent for all requests. This credential is sent over to the api as well for any direct api links (like files) and will require authentication on the api side which will fail unless the user exists (in the users table) with the same password. Big problem here currently is everyone must use the same account currently.

With this approach, an authtoken is never generated.

Code changes to allow this scenario:

Allow user to login as different wiki accounts while still using a dummy account to get into the wiki. As suggested by Pete, the API needs to first look at the authtoken and then look at credentials in order to authenticate. The wiki (users table) "anonymous" user would need to be renamed or a new user created that would match the 'dummy account'. This will allow authtoken-less requests to be fulfilled by the api with correct permissions granted. If a user chooses to login to the wiki as someone else, this will work as normal with the login page calling post: users/authenticate returning an authtoken. Clicking logout will delete the authtoken and revert back to using the dummy/anonymous user.

Scenario 2: .htpasswd containing wiki accounts

The admin might want to store all possible wiki credentials in the .htpasswd file (ISPs often use this approach). This allows the uber private wiki by requiring authentication before any wiki page can be seen.

Code changes to allow this scenario:

A Deki Authentication Service needs to be written along the lines of LDAP/Drupal to allow authenticating requests containing credentials and associating them with wiki accounts. The 'htpasswd' command is used to build the .htpasswd file with a given username/password. Unfortunately this command uses the kernel Crypt() system call which somehow is able to create a different password hash on subsequent calls on the same password. This needs more research to see if/how it's feasible. If not feasible, a pass through authentication service can be written that is configured with a admin-entered URI and will simply delegate validating given credentials with that URI.

Scenario 3: Disable Login page on front end

Another approach is to have the front end authenticate with the api without having to use a login screen. The same 401 dialog box as used with above approaches would be used to enter credentials. This would use whatever already existing auth services are setup and would allow users to automatically be created the same way as via the login page.

Code changes to allow this scenario:

Have a setting in DekiWiki UI that will enable this mode. Have index.php return a 401 status if there are no credentials in the request or if the credentials aren't valid. Credentials are verified by calling POST: users/authenticate.
Whether or not users are auto-created upon successful auth can be a UI setting (that will decide if POST or GET users/authenticate is called).

Settings needed on the front end to support this:

• Disable login page (bool)
  
• Default service id (int)
• Auto-create users (bool)
  

Login/logout link and current user label on top right of UI

Code for this may need to be looked at to ensure that a user is only logged in to the wiki when an authtoken is present. Logging out simply deletes authtoken.