Differences

This shows you the differences between two versions of the page.

--- plugin:authhttp [2014-05-17 17:25] – Fix typo 78.53.205.63
+++ plugin:authhttp [2023-09-20 15:15] (current) – ggauth page does not exist anymore 5.147.81.239
@@ Line 1: / Line 1: @@
-====== HTTP authentication plugin ======
+====== HTTP Authentication Plugin ======
 ---- plugin ----
@@ Line 6: / Line 6: @@
 email      : pieter@hollants.com
 type       : auth, action
-lastupdate : 2014-05-17
+lastupdate : 2023-09-20 #yyyy-mm-dd
-compatible : Weatherwax, Binky, Ponder Stibbons
+compatible : Jack Jackrum, Igor, Elenor of tsort, Ponder Stibbons, Hrun, Detritus, Frusterick Manners, Greebo, Hogfather
 depends    :
 conflicts  :
@@ Line 19: / Line 19: @@
 ----
-:!: This is an authentication plugin for DokuWiki Weatherwax 2013-05-10a and later! For a solution for earlier DokuWiki versions please refer to [[auth:ggauth|ggauth]].
+Last successfully tested: 2023-09-20 with PHP 8.0.30 and DokuWiki 2023-04-04a "Jack Jackrum"
 ===== Description =====
-This auth plugin should be installed in certain scenarios if you configured your Webserver to do HTTP authentication. If you did not, the plugin will report an error and DokuWiki's ACL won't work.
+This auth plugin is for you if you don't want your users to have to login
+through the login form all the time when you have instead already configured
+your webserver to perform some sort of authentication (eg. HTTP Basic or
+NTLM authentication). In that case, the Webserver provides a user's
+credentials to PHP scripts through the superglobal variables
+''$_SERVER['PHP_AUTH_USER']'' and ''$_SERVER['PHP_AUTH_PW']''.
-The very moment you enable HTTP authentication in the Webserver and a user authenticates successfully, PHP provides these credentials to PHP scripts through ''$_SERVER['PHP_AUTH_USER']'' and ''$_SERVER['PHP_AUTH_PW']''. Out of the box, DokuWiki will pick these up and pretend the user supplied those through the login form. It will perform authentication using the configured auth plugin and, if successful, show the user (and the admin) options depending on the auth plugin's capabilities.
+Out of the box DokuWiki will already pick these up and pretend the user
+supplied those through the login form. It will perform authentication using
+the configured auth plugin (usually authplain) and, if successful, show the
+user (and the admin) options depending on the auth plugin's capabilities.
 This all works out as long as
-  * **either** DokuWiki's auth plugin does not have capabilities such as //change login name//, //change password//, //add user//, //edit user//, //delete user//
+  * **either** DokuWiki's auth plugin does not report capabilities such as //change login name//, //change password//, //add user//, //edit user//, //delete user// so that DokuWiki consequently does not expose these controls to the user
   * **or** the Webserver and DokuWiki's auth plugin use **the same** source for their authentication.
-If the first condition is not true, the user can change his password through the "User profile" function. The admin, through the "User manager", can also change his login name, delete him or add him with a different login name. In all of these scenarios, if the second condition is **also** not true, there will be inconsistencies between the HTTP authentication (which might eg. use an old password) and DokuWiki's auth plugin (which might have stored a new password somewhere else), causing Single Sign-On to break and errors to be displayed.
+If the first condition is not true, ie. the plugin **does** provide the named
+capabilities, the user could attempt to change his password through the
+"User profile" function. The admin, through the "User manager", could also
+change his login name, delete him or add him with a different login name.
-Note that this is not a bug in DokuWiki - DokuWiki can't in any way know how your Webserver's HTTP authentication has been set up. For example, if you configure your Webserver to display the username/password prompt but not validate them, there is no problem at all since DokuWiki is the only entity doing actual authentication. This might actually be a considerable setup since there is not much point in authenticating twice. The upper part of [[tips:httpauth-passthru|httpauth-passthru]] describes this.
+Now if the second condition is **also** not true, there can be inconsistencies
+between the HTTP authentication (which might eg. use an old password) and
+DokuWiki's auth plugin (which might have stored a new password somewhere
+else), causing Single Sign-On to break and errors to be displayed.
+Note that this is not a bug in DokuWiki - DokuWiki can't in any way know how your Webserver's HTTP authentication has been set up.
+For example, if you configure your Webserver to display the username/password prompt but not to actually validate them, there is no problem at all since DokuWiki (without this plugin) is the only entity doing actual authentication. This might actually be a considerable setup since there is not much point in authenticating twice. [[tips:httpauth-passthru|httpauth-passthru]] describes this.
 This plugin does it the other way round. It assumes that **the web server** already did the authentication and essentially annuls DokuWiki's own authentication by providing a minimalistic ''checkPass()'' method which does not really authenticate. It merely checks that DokuWiki's idea of username/password equals the HTTP authentication credentials which should always be the case (except if you did not enable HTTP authentication in your Webserver).
-DokuWiki expects some things that HTTP authentication does not provide and where the plugin thus has to improvise:
+Note however that DokuWiki expects information that HTTP authentication does not provide and where the plugin thus has to improvise:
-  * the user's **real name**: authhttp will simply return the user's login name here. This may not look nice but there's no way of knowing his real name.
+  * the user's **real name**: authhttp will simply return the user's login name here.
   * the user's **email address**: authhttp makes one up by appending a configurable domain part to the user's login name. This will generate email addresses that will probably not work. There is not really a way around this, so you might want to disable email-related functions in DokuWiki.
   * the user's **groups**: authhttp will simply put **all** users in DokuWiki's "defaultgroup". Users whose login names are listed in "specialusers" will also be reported to be member of "specialgroup". If you did not modify DokuWiki's "superuser" configuration setting default of "@admin", you should leave this setting at "admin" as well and put users supposed to be admins in "specialusers".
-If these limitations are not acceptable, you might want to combine authhttp with [[plugin:authsplit]]. authhttp comes with an action plugin that improves integration with [[plugin:authsplit]]:
+If these limitations are not acceptable, you might want to combine authhttp with another plugin, [[plugin:authsplit]]. authhttp comes with an action plugin that improves integration with [[plugin:authsplit]]:
   * When authhttp is the primary auth plugin for [[plugin:authsplit]], there could be the case that while users are known to authhttp, they aren't to the secondary auth plugin yet, so they'd have to register (unless [[plugin:authsplit]]'s ''autocreate_users'' feature is used). In this scenario, the username for registration should match the HTTP authentication username. Also, the login form should be hidden because there is not much sense in offering a form-based login when HTTP authentication is used. authhttp's action plugin takes care of all that.
   * When authhttp is used on its own, ie. without [[plugin:authsplit]], users are **always** logged in and "registered", so authhttp's action plugin won't have a visible effect.
@@ Line 48: / Line 66: @@
 ===== Installation =====
-Download the latest version from [[https://github.com/pief/authhttp/zipball/master|GitHub]] and rename the extracted directory to ''authhttp'', otherwise the plugin won't work.
+Search and install the plugin using the [[plugin:extension|Extension Manager]]. Alternatively, download the latest version from [[https://github.com/pief/authhttp/zipball/master|GitHub]] to the ''lib/plugins'' and rename the extracted directory to ''authhttp'', otherwise the plugin won't work. Please refer to [[:Plugins]] for additional info on how to install plugins in DokuWiki.
-Please refer to [[:Plugins]] for additional info on how to install plugins in DokuWiki.
 ===== Configuration and Settings =====
-  * **emaildomain**: The domain to append to login names to generate email addresses.
+  * **usernameregex**: a regular expression specifying the username part of the HTTP authentication login name (the string in $_SERVER['PHP_AUTH_USER']). Examples:
-  * **specialusers**: The login names of users to be put in the special group. You can list multiple login names separated by Space.
+    * ''.+'' for UNIX/passwd environments (ie. user name = login name)
-  * **specialgroup**: The name of the special group.
+    * ''^[^@]+'' for Kerberos environments with ''//user@domain//'' login names, uses everything before the ''@'' character as user name
+    * ''\\[^\\]+$'' for Windows domain environments with ''//DOMAIN\USER//'' login names, uses everything after the ''\'' character as user name
+  * **emaildomain**: the domain to append to login names to generate email addresses.
+  * **specialusers**: the login names of users to be put in the special group. You can list multiple login names separated by space.
+  * **specialgroup**: the name of the special group.
-Note: when authhttp is used together with [[plugin:authsplit]] and authhttp is the primary auth plugin for [[plugin:authsplit]], all three configuration settings above will have no effect any longer due to the way [[plugin:authsplit]] works.
+**Note:** when authhttp is used together with [[plugin:authsplit]] and authhttp is the primary auth plugin for [[plugin:authsplit]], the last three configuration settings above will have no effect any longer due to the way [[plugin:authsplit]] works.
 ===== Change Log =====
-{{rss>https://github.com/pief/authhttp/commits/master.atom 5 date 1h}}
+{{rss>https://github.com/pief/authhttp/commits/master.atom date}}
 ===== Credits =====
-This plugin is based on ideas in [[auth:ggauth|the ggauth auth backend]] by [[mailto:grant@lastweekend.com.au|Grant Gardner]]. Grant does not actively maintain ggauth anymore, so an update for the new auth plugins concept is unlikely. Also, his "http" auth backend uses ''trustExternal()'' which eg. does not support group memberships if used on its own, ie. without the [[auth:ggauth|ggauth "split" auth backend]].
+This plugin is based on ideas in the "ggauth" auth backend by [[mailto:grant@lastweekend.com.au|Grant Gardner]]. Grant has not been maintaining ggauth for DokuWiki versions after "WeatherWax". Also, his "http" auth backend uses ''trustExternal()'' which eg. does not
+support group memberships if used on its own, ie. without the ggauth "split" auth backend.
 ===== Discussion =====