Extension talk:HttpAuth
Add topicHook HttpAuthPlugin::autoAuthenticate failed (solved)
[edit]I encountered the following error:
Detected bug in an extension! Hook HttpAuthPlugin::autoAuthenticate failed to return a value; should return true to continue hook processing or false to abort.
I'm not sure if this changed in a later version of MediaWiki, but I solved it by adding
return 1;
at the end of the autoAuthenticate() function.
--Divide 21:00, 14 September 2007 (UTC)
I had this same problem, and solved it with pretty much the same thing (return true;). Incase it helps someone in the future, heres roughly the specs of the problem system:
- MediaWiki: 1.11.2
- PHP: 5.2.4-2ubuntu5.3 (apache2handler)
- MySQL: 5.0.51a-3ubuntu5.1
Kgoetz 03:52, 5 September 2008 (UTC)
Using PHP as a CGI rather than an Apache module
[edit]If you're using php as a CGI rather than a apache module, you can get this plugin to work by replacing all instances of PHP_AUTH_USER in the module and the lines added to LocalSettings.php with REMOTE_USER. -Mork the delayer
Is it possible to disable the auto-creation of new accounts? How?
Not working for me...
[edit]This extension does not work for me on my Mac Server. Here is some info:
PHP Version 5.1.2 Apache/1.3.33
Don't you have to call this?:
header( 'WWW-Authenticate: Basic realm="Private"' );
I don't see where it calls that...
Thanks,
John
- I guess it expects you to do that by .htaccess -- Duesentrieb ⇌ 00:21, 13 April 2007 (UTC)
Why do I get this warning? (solved)
[edit]Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file. in /is/htdocs/wp1XXXXXXXX_XXXXXX/www06/UTILISE/wiki/extensions/HttpAuthPlugin.php on line 261
I am using a virual server and can not edit the PHP Setup
allow_call_time_pass_reference needs to be true, and can be set in the PHP-setup, HOST-Europe lets you manipulate this, others may be too.
(--Mrmuehle 16:23, 17 May 2007 (UTC))
I've read in various PHP forums that allow_call_time_pass_reference should not be enabled for general security reasons.. is there another solution to get rid of these warning messages?
This is great - what about htgroups?
[edit]This plugin works well for me - good work Jeremiah. However I'd like something that can keep mediawiki user groups in sync with apache's htgroup file in a similar manner. Unfortunately for me php's $_SERVER array does not seem to contain the groups a user belongs to. Ideas appreciated.
(--Dkerse 06:54, 17 July 2007 (UTC))
Disable manual account creation
[edit]This is a nice plugin and I would like to be able to disable manual signups for my wiki. Unfortunately $wgGroupPermissions['*']['createaccount'] = false; does not work any more :(
- Have you tried $wgGroupPermissions['user']['createaccount'] = false; ??
- '*' will not match, because with HttpAuth everybody in this wiki is (at least) a user and no more anonymous --80.153.10.122 08:30, 9 July 2010 (UTC)
User authenticated from http, but identified from cookies (and minor suggestions)
[edit]Great plugin.
Some suggested corrections:
User authentication (verifying username/password) gets from httpRequest. But identification goes from cookies.
To reproduce: login into wiki as user1, then as user2, then as user1 again and look at the top of the wiki page (where logged user name is specified). Don't logout. Restart browser instead.
Fix: insert this into HttpAuthPlugin.php, in the function autoAuthenticate, replace
if($user->mId != 0) { return 0; }
with
if ( strtolower($user->mName) != (strtolower($this->getNameSub($_SERVER['PHP_AUTH_USER']))) ) { $user->loadDefaults(); } if($user->mId != 0) { return 0; }
To disable "Create new account" replace whole function modifyUITemplate with:
function modifyUITemplate( &$template ) { $template->set('useemail', false); $template->set('remember', false); $template->set('create', false); $template->set('domain', false); $template->set('usedomain', false); }
To disable "change password" option from UserPreferences replace whole function allowPasswordChange with:
function allowPasswordChange() { return false; }
and replace function authenticate with:
function authenticate( $username, $password ) { if(strcmp(strtolower($username),strtolower($_SERVER['REDIRECT_REMOTE_USER'])) == 0) return true; else return false; }
To remove Login/Logout from every page edit includes/SkinTemplate.php. Find lines:
$personal_urls['logout'] = array(
'text' => wfMsg( 'userlogout' ),
'href' => self::makeSpecialUrl( 'Userlogout',
$wgTitle->isSpecial( 'Preferences' ) ? '' : "returnto={$this->thisurl}"
),
'active' => false
);
and
$personal_urls['login'] = array(
'text' => wfMsg('userlogin'),
'href' => self::makeSpecialUrl( 'Userlogin', 'returnto=' . $this->thisurl ),
'active' => $wgTitle->isSpecial( 'Userlogin' )
);
And comment them (or remove). In my case (mediawiki 1.11.0) numers of those lines: 546..552 and 577..581
Using proxy - consider replacing every occurrence of PHP_AUTH_USER with REDIRECT_REMOTE_USER (inside HttpAuthPlugin.php)
B aniaczek 14:49, 19 October 2007 (UTC)
IMPORTANT
[edit]If you also enable anonymous browsing make absolutely sure its behaving correctly. In some situations, PHP_AUTH_USER gets set regardless of a successful login. You can test with:
curl http://baduser:badpassword@your.domain/wiki/ | grep -i baduser
if you see a page that looks like the bad user is logged in, your setup is misconfigured. In previous install versions it was suggested to use PHP_AUTH_USER, always use REMOTE_USER as it only gets set on successful login.
Error with mediawiki 1.12.0 when an account does not exist
[edit]When logging through http without an existing mediawiki account generates an exception. Then if you refresh, the account was created and all is ok.
Removal of disconnect link
[edit]Indeed since the auth is done through http, the disconnect link should be removed.
Problems
[edit]I use mediawiki1.7 with php 5.2.0 and after install HttpAuth plugin all work fine for me except new account creation page. When I try to create a new account I recive the following error:
A database query syntax error has occurred. The last attempted database query was: (SQL query hidden) MySQL returned error "1062: Duplicate entry 'WikiSysop' for key 1 (localhost)".
Ecerutti 21:56, 18 June 2008 (UTC)
Solution: I have got this to work for Mediawiki 1.14, by applying three changes:
- Follow the rewrite suggestion concerning the UserLoadFromSession hook in LocalSettings.php
- Modify function userExists as to always return true
- In function autoAuthenticate comment out $user->saveSettings(), as this is the cause of your SQL error.
Bart Du Bois, 16:11, 24 February 2008 (UTC)
SHA instead of MD5
[edit]Is there a way to get mediawiki to use SHA-1 instead of MD5? I believe Apache supports SHA-1 passwords. Would it therefore be possible to configure apache to do the http auth against the mediawiki users table using SHA-1?
In its present state, this extension does the reverse of what I'm trying to accomplish. I'd like to manage users via mediawiki, but use http auth.
- I'm just about to do the same. I set up Apache with mod_auth_mysql. With help of http://richardkmiller.com/184/password-protecting-mediawiki-with-mod_auth_mysql I managed to set up HTTP Auth using a view of MediaWiki's user table. I may write an extension to log in users authenticated via HTTP Auth into MediaWiki automatically as I didn't see an extension doing this already. I'll check http://www.mediawiki.org/wiki/Extension:AutomaticREMOTE_USER and perhaps modify it to match my requirements. --Goetz 13:52, 15 June 2009 (UTC)
Tip: PHP+FCGI
[edit]I found a more elegant workaround using php as fast-cgi, see the detailed informations. It works like a charm on my server.
Note: you might want to add the code as prepended file in php.ini so it applies globaly and without any other change. 84.227.28.87 14:58, 19 July 2009 (UTC)
MediaWiki 1.15.1 and Integrated Authentication using IIS (solved)
[edit]I'm interested in setting up a Wiki (using MediaWiki) in a Windows environment (MySQL 5.1.39, PHP 5.2.11, and IIS 7, with users using Windows Desktops). IIS will be configured for Integrated Authentication (i.e. no anonymous access allowed), and I would like WikiMedia to trust the REMOTE_USER header variable, and create a MediaWiki account for the user if it does not already exist.
This extension is pretty close to what I'm looking for.
I followed the directions (and updated the code to use the UserLoadFromSession hook) and I added the following code to LocalSettings.php:
session_start(); require_once("$IP/extensions/HttpAuthPlugin.php"); $wgAuth = new HttpAuthPlugin(); $wgHooks['UserLoadFromSession'][] = array($wgAuth,'autoAuthenticate');
I removed the if statement around the last 3 lines to ensure they are called (for testing purposes).
I wasn't getting the results I wanted. The upper right hand corner of the web pages were still reading "0:0:0:0:0:0:0:1 | Talk for this IP | Log in / create account" instead of it listing the user account ("domain\username). I think the root cause for my issues is that the function "autoAuthenticate" is not actually being called. Ever. To be sure, I added some code to the top of that function that would raise an exception, but I'm never seeing any errors.
Solution: the UserLoadFromSession hook started working when I moved the above code down to the bottom of the LocalSettings.php file.
Alternative solution: using common names (instead of userids) as user account names
[edit]Contribution by --Wikinaut 23:20, 18 December 2009 (UTC)
The present HttpAuth extension uses the unique userids from the authentication step as wiki user account names - unless you use name substitution as suggested in the article main page, for small wikis.
I propose the following modification for which code will be published soon:
- set
$wgAllowRealName = false;
to suppress showing or altering the userid: the username is always the real (common) user name, not user's nickname - create new accounts with the unique userid as real name in
$user->mRealName
- use and show common name "Joe Doe" as it is retrieved from LDAP directory as wiki user account name for this userid
- common name conflict resolution: different users having the same common name "Joe Doe" get different account names so that their contributions and user pages can be distinguished: the first gets "Joe Doe", the second and further get "Joe Doe (userid)", so that wiki user account names are distinct; the layout of such doublure names can be adapted in the extension code.
Disabling Special:UserLogin and Special:UserLogin ; removal of login and logout links
[edit]In LocalSettings.php you can use the following code to unset (disable) unwanted built-in special pages. The general message "You have requested an invalid special page." is shown if users try to access such unset special pages.
// see http://www.mediawiki.org/wiki/Manual:Hooks/SpecialPage_initList
// and http://www.mediawiki.org/w/Manual:Special_pages
// and http://lists.wikimedia.org/pipermail/mediawiki-l/2009-June/031231.html
// disable login and logout functions for all users
function LessSpecialPages(&$list) {
unset( $list['Userlogout'] );
unset( $list['Userlogin'] );
return true;
}
$wgHooks['SpecialPage_initList'][]='LessSpecialPages';
// http://www.mediawiki.org/wiki/Extension:Windows_NTLM_LDAP_Auto_Auth
// remove login and logout buttons for all users
function StripLogin(&$personal_urls, &$wgTitle) {
unset( $personal_urls["login"] );
unset( $personal_urls["logout"] );
unset( $personal_urls['anonlogin'] );
return true;
}
$wgHooks['PersonalUrls'][] = 'StripLogin';
Tested with MediaWiki 1.15.1 and PHP 5.2.12. --Wikinaut 15:02, 14 January 2010 (UTC)
Using this extension deadlocks the server under load (SOLVED)
[edit]We are trying to set up a wiki for our internal use (no outside access) and we authenticate against ldap with apache's mod_authnz_ldap, so HttpAuth is precisely what we need. But we have a problem. Using this extension hangs the server under anything more than very light load. Even one user can cause the hang by refreshing a page repeatedly. Apache just grabs all cpu and deadlocks, not outputting anything. I suspect there's a race condition somewhere in the cookie checking mechanism. Account creation works as expected, and everything else works until the server hangs. Apache does not come out of the deadlock, it just sits there consuming all cpu cycles until it's shut down manually.
Tried both Mediawiki 1.15.1 and 1.15.2, both php 5.2.6 and 5.3.2, and the exact same thing happens.
Any help appreciated. --130.232.194.146 06:06, 9 April 2010 (UTC)
- This turned out to be an incompatibility issue between mod_authnz_ldap and Mediawiki (or mod_perl). The problem occurs even when HttpAuth is not in use. Solved by ditching mod_authnz_ldap and HttpAuth and moving to the ldap authentication plugin. --130.232.194.146 09:04, 13 April 2010 (UTC)
Warning: require_once(AuthPlugin.php) [function.require-once]: failed to open stream: No such file or directory in [...]/mediawiki/extensions/HttpAuthPlugin.php on line 38
[edit]Is there a file missing?
- Try to change the statement in line 38 of $IP/extensions/HttpAuthPlugin.php to
require_once( "$IP/includes/AuthPlugin.php" );
- $IP stands for the Installation Path (or "directory") of your MediaWiki installation, the same directory that holds LocalSettings.php , index.php etc..
- In a correctly installed MediaWiki with this extension, it works (it should work) without this modification.
- Tip: if you register and write as a logged-in user and watch this page, you can reveive an e-mail notification if someone changes the page.
- --Wikinaut 08:14, 19 March 2011 (UTC)
PHP Fatal error: Call to undefined method User::SetupSession() in $IP/mediawiki/extensions/HttpAuthPlugin.php on line 245
[edit]- MediaWiki: 1.19.1
User::SetupSession() function was deprecated for some time, and it appears that it has been finally removed from $IP/mediawiki/includes/User.php
- Try to change the statement in line 245 of $IP/mediawiki/extensions/HttpAuthPlugin.php to
if( !$wgCommandLineMode && !isset( $_COOKIE[session_name()] ) ){
//User::SetupSession();
wfSetupSession();
}