Learn about DokuWiki
Learn about DokuWiki
This is an old revision of the document!
This extension has not been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues.
Similar to authchained
This is an authentication plugin for DokuWiki Weatherwax (2013-05-10a) and later! For a solution for earlier DokuWiki versions please refer to ggauth.
authsplit, while technically being an auth plugin, does not do any authentication itself. Instead, it splits DokuWiki's different authentication method calls among two other auth plugins that will do the actual work:
This suggests using authsplit to combine a rather primitive, yet for some reason particularly useful auth plugin with an auth plugin that is more powerful, yet for some reason not useful enough if used on its own.
The example that comes to mind is to use authhttp as primary auth plugin and authplain as secondary auth plugin, thereby combining the advantages of reusing HTTP authentication information with an auth plugin that supplements everything HTTP authentication can't offer, such as email addresses. This is the scenario authsplit has been tested with, but in theory it should work with other auth plugin combinations as well. Feel free to give me feedback on other working combinations.
As authsplit has to orchestrate two auth plugins and the user's state in them, it is possible that a user is known to one of the two plugins only or stored with different data. This may lead to the effect that while one auth plugin knows about him or her, (s)he is still being reported to DokuWiki as being unknown. Since these effects may not be particularly intuitive at first sight, you should read the following explanations carefully. It is essential to really understand how authsplit works in order to prevent accidental lockout or security breaches due to improper configuration and/or unexpected behavior!
In order to understand how authsplit works one doesn't really get around learning about DokuWiki's authentication system. Please refer to Auth plugins for fundamental basics.
authsplit maps DokuWiki's authentication method calls as follows:
checkPass(): this is DokuWiki's method that validates login names and passwords. authsplit will first make sure that the primary auth plugin validates both login name and password successfully. If a user is not known here, he is not known to DokuWiki at all.
getUserData(): this is the method DokuWiki uses eg. to retrieve the user's real name for display in the “Logged in as” section in the upper right (if you use the default “DokuWiki” template). authsplit will call the primary auth plugin's
getUserData()method only to make sure the user exists there and then return the secondary auth plugin's
getUserData()information to DokuWiki. Thus, a user has to be known to both auth plugins, but the secondary's user information matters. Any group membership information returned from the primary auth plugin will be silently ignored.
createUser(): this is the method that gets called if users register themselves or the Admin uses DokuWiki's user manager to create an account for them.
modifyUser(): where authsplit routes a change depends on the actual change itself:
deleteUser(): authsplit will always route delete user requests to the secondary auth plugin only. This is because it can't know whether user accounts known to the primary auth plugin are yet in use by other software. Thus, deleting a user with the user manager will remove knowledge of his or her existance in DokuWiki only.
getUserCount(): authsplit will always route these method calls to the secondary auth plugin, following the concept that DokuWiki's user manager is supposed to manage DokuWiki users in the first place. Thus, even if the primary auth plugin offered these methods, the user lists and counts obtained there would not be of much use since, unless
autocreate_usersis enabled, only the secondary auth plugin would really know which users resp. how many users really had DokuWiki access.
retrieveGroups(): authsplit will always route these method calls to the secondary auth plugin since, by design, that is where group membership information comes from.
cleanUser(): authsplit will always route these method calls to the primary auth plugin since that is the one that dictates restrictions on login names.
cleanGroup(): authsplit will always route this method call to the secondary auth plugin since that is the one that dictates restrictions on group names.
So to summarize which auth plugins are involved in which method calls:
|Primary auth plugin||Secondary auth plugin|
| ||Stored here|| Existance required
(Can create if enabled)
| ||Existance required||Stored here|
| ||Can create here if supported||Created here|
| ||Depends on the information being modified|
| ||-||Deleted here|
| ||-||Stored here|
| ||-||Counted here|
| ||-||Created here|
| ||-||Retrieved here|
| ||Determined here||-|
| ||Determined here||-|
| ||-||Determined here|
Of course, this example is not a particular useful combination. After all, why would you want to store users in a DokuWiki-specific textfile and put additional information in a MySQL database…
As mentioned above, using authhttp as the primary auth plugin and authplain as the secondary auth plugin is the prime use case. You could of course also try to combine authhttp with authmysql, or authldap with authplain etc. In effect, just try things out and give me feedback on working combinations and their particular use cases.
Download the latest version from Github and rename the extracted directory to
authsplit, otherwise the plugin won't work.
Please refer to Plugins for additional info on how to install plugins in DokuWiki.
authsplit itself uses the following configuration settings:
primary_authplugin: This is the DokuWiki auth plugin that will be used to validate login names and passwords. An example candidate is my authhttp plugin.
secondary_authplugin: This is the DokuWiki auth plugin that will be used to store additional user information such as real names, email addresses and groups.
autocreate_users: If enabled, authsplit will automatically create user accounts for any users that exist in the primary auth plugin, but are yet unknown in the secondary auth plugin. If disabled, users will either have to register themselves or created by the admin (eg. if registration has been disabled).
Sample settings for using authhttp and authplain, without automatic user creation:
$conf['authtype'] = 'authsplit'; $conf['plugin']['authsplit']['primary_authplugin'] = 'authhttp'; $conf['plugin']['authsplit']['secondary_authplugin'] = 'authplain'; $conf['plugin']['authsplit']['autocreate_users'] = 0;
Note that you'll have to take some of the used auth plugin's settings into consideration whereas some may not apply any longer due to the way authsplit works. For example, when using authhttp as the primary auth plugin, authhttp's configuration settings no longer have any effect since all email addresses and group information come from the secondary auth plugin instead.
Please use the Discussion page for user comments.