Extension:HttpAuth
From MediaWiki.org
|
Release status: beta |
|||
|---|---|---|---|
| Implementation | User identity | ||
| Description | Automatically authenticates from Apache HttpAuth credentials. | ||
| Author(s) | Jeremiah Orem | ||
| Last Version | 0.1 (10-03-2008) | ||
| MediaWiki | 1.5 and up | ||
| License | MPL | ||
| Download | Download github changelist |
||
|
|||
|
|||
|
check usage (experimental) |
|||
Contents |
[edit] Overview
This extension only works with MediaWiki instances setup behind HTTP authentication. It pulls usernames from $_SERVER['PHP_AUTH_USER']. The extension will then either log the user on to MediaWiki if the user name exists in the database or create a new user if it does not.
[edit] Installation
Drop the code from the download section in $IP/extensions/HttpAuthPlugin.php. Note: $IP stands for the root directory of your MediaWiki installation, the same directory that holds LocalSettings.php.
Edit LocalSettings.php and add:
session_start(); if ((!empty($_SERVER['PHP_AUTH_USER']) && !empty($_SERVER['REMOTE_USER'])) || $_COOKIE[$wgDBserver . 'UserID']) { require_once("$IP/extensions/HttpAuthPlugin.php"); $wgAuth = new HttpAuthPlugin(); $wgHooks['AutoAuthenticate'][] = array($wgAuth,'autoAuthenticate'); }
[edit] Attention
- If authentication does not work try to replace 'PHP_AUTH_USER' with 'REMOTE_USER' in HttpAuthPlugin.php (I needed to do so under MediaWiki 1.13.2)
- Under MediaWiki 1.13 (and later), the hook name has changed from AutoAuthenticate to UserLoadFromSession. You need to change the last line of the above appropriately:
- $wgHooks['AutoAuthenticate'][] = array($wgAuth,'autoAuthenticate');
- change to
- $wgHooks['UserLoadFromSession'][] = array($wgAuth,'autoAuthenticate');
[edit] Name Substitution
This extension also supports name substitution. For example if the user's Http Auth username is foo and the user would like their wiki name to be bar we can do this:
$wgAuth->addNameSub('foo','bar');
Do this directly after instantiating the object $wgAuth
[edit] Allowing Anonymous Browsing
If you want to allow anonymous users to browse the site without hitting a basic auth popup and you have clean URLs configured you can place some code like this near the top of your LocalSettings.php script:
function redirect($path) { $host = strlen($_SERVER['HTTP_HOST'])?$_SERVER['HTTP_HOST']:$_SERVER['SERVER_NAME']; header('Location: http://'.$host.$path); header('Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0'); } if ($_GET['title'] == 'Special:Userlogin') { redirect('/Special:Userlogin?returnto='.$_GET['returnto']); } if (strpos($_SERVER['REQUEST_URI'], '/Special:Userlogin') !== false) { if ($_GET['returnto']) { redirect('/'.$_GET['returnto']); } else { redirect('/Main_Page'); } }
This will make sure that whenever a user clicks the 'log on' link they are redirected to /Special:Userlogin (if necessary). Apache can then be configured with the authentication inside a <Location "/Special:Userlogin"> directive, which will pop up the authentication box for that URL only. Finally, when they reach that URL (having authenticated) we redirect them to wherever they came from, if that information was provided by the link. The user should then be logged in.
Note: This code has not been tested in multiple server configurations - expect to need to tweak this code for your specific setup! Also note, this does not easily allow users to log out.
[edit] Under FastCGI (a bit of a hack)
Neither PHP_AUTH_USER nor PHP_AUTH_PW are available if you are running under FastCGI, and REMOTE_USER is known as REDIRECT_REMOTE_USER. I don't know why it needs the password, I assume it stores it in MediaWiki as well as in your htpass file. For our application, where the site will only ever be used in this way with HTTP auth, this isn't a problem, so I copied over the user name and set a fake password as shown below. Note, I don't advise using something as simple as the string 'fakepassword' as the fake password, I used something with a load of special characters, in order to at least try to be as sure as possible that it couldn't be guessed in the case it accidentally became accessible due to an error in the httpd config.
I put the following into LocalSettings.php, rather than the code shown at the head of the page. Note that I've not been able to test this widely, so regard it as experimental, and to be honest, something of a hack. I have MediaWiki 1.12.0, php 5.1.2 and apache 2.0.55.
session_start(); if ((!empty($_SERVER['REDIRECT_REMOTE_USER'])) || $_COOKIE['fpwiki_en_UserID']) { $_SERVER['REMOTE_USER']=$_SERVER['REDIRECT_REMOTE_USER']; $_SERVER['PHP_AUTH_USER']=$_SERVER['REDIRECT_REMOTE_USER']; $_SERVER['PHP_AUTH_PW']='fakepassword'; require_once("$IP/extensions/HttpAuthPlugin.php"); $wgAuth = new HttpAuthPlugin(); $wgHooks['AutoAuthenticate'][] = array($wgAuth,'autoAuthenticate'); }
[edit] When it doesn't work
In MediaWiki 1.13 (and later), the hook name has changed from AutoAuthenticate to UserLoadFromSession. See #Attention above.
This plugin code fails with MediaWiki version 1.12.0 and PHP version 5.1.6 though this ammend may be applicable to other versions as well.
In the autoAuthenticate function you need to change the line that reads:
$this->initUser(&$user);
so that it now reads this:
$this->initUser($user);
Plus you need to change the function definition for initUser so that instead of:
function initUser( &$user ) {
it now reads:
function initUser( $user )
otherwise you get an error about pass by reference syntax which has been deprecated for PHP5.
Back in the autoAuthenticate function you need to change the one line that currently reads:
return 0;
to:
return false;
Plus add a new line after the last saveSettings line which reads:
return true;
I think this is because of some kind of change in either PHP's default return values or the MediaWiki API for auth plugins has become stricter.
Also - I've no idea what someone's going on about when they mention start_session earlier in this document... All I had to do was paste the one block of code in to the bottom of my LocalSettings.php and be done with it.
[edit] My Experience
Tried this and had some issues with the site showing up with a error 500 each time i logged in. Then after refreshing the page it worked fine. I also noticed that there wasn't a mechensim that logged me out. I only tested in IE7, but I was not able to logout in any safe way. Maybe these issues will get resolved, until then I'm stuck with double authentication.
- No idea about the Error, but Http-Authentication does not have a mechanism for logout. This is a limitation of the HTTP-Protocol (see en:Basic_access_authentication#Disadvantages), there is nothing an extension can do about it. If you want a "real" login (and logout), don't use HTTP-Auth. -- Duesentrieb ⇌ 07:49, 27 May 2008 (UTC)
- Well, sort of. HTTP authentication does have a logout of sorts - sending back a 401 Unauthorized response is intended to cause user agents to assume whatever credentials they used are no longer valid. Per the RFC: "[If] the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials." Unfortunately, in practice this drops them immediately back to the auth dialog - the workflow becomes "click logout, then cancel the password prompt," which still sucks. It also acts... strangely if multiple concurrent requests are in progress and one of them invalidates the credentials. I don't see a way to cleanly implement Mediawiki's own logout semantics overtop of HTTP auth. 76.10.176.194 (Owen Jacobson)
-
- Is this the right place to discuss? Anyhow, there is a trick to logout HTTP Basic Auth: get the URL https://logout:logout@host/, your browser will reset the realm. Nobody uses, or at least should use, this in applications, but uses to test application without close the browser. -- Anonymous Wed Jul 22 08:40:40 BRT 2009
- I'm not a PHP expert by any means, but the 500 error seems to be a missing return statement at the end of function autoAuthenticate. I added return true; after $user->saveSettings();, that is, line 266 of HttpAuthPlugin.php. This seems to work, but again, I'm no expert, YMMV. I'm not really in a position to test thoroughly except in relation to our particular system, and I don't know that it's worth a patch for one line of code; perhaps the maintainer could take a look next time they check this page? Epitaph 17:50, 1 July 2008 (UTC)
[edit] Verify Security
Ensure your install is working correctly by not only checking to see if logging in works but also see if by passing bad information it keeps you out:
curl http://baduser:badauth@your.domain/wiki/Main_Page