AuthUserFile /dev/null

http://subfiles.net/mediawiki/mediawiki-extension-mod_auth_mysql-v0-1.zip

(mediawiki-1.15.1)

feel free to delete all my comments and you can offer the link on top (or offer the zip as well, it’s released under AGPL).

Right now I have not found a solution to circumvent that with built in methods.

There is a mediawii hook called UserCryptPassword ( &$password, &$salt, &$wgPasswordSalt, &$hash ) that can overwrite the hash creation. this could be used to create a mediawiki php extension (will try that now) incorporating that routine. maybe this already exists as well.

this is identified cause why mysql auth didn’t work any longer mediawiki in my case.

Need to make more checks.

user_name varchar(255) – utf8_bin –
user_password tinyblob – - BINARY

I need to check wether or not blobs are suppored. I even created a new user AFTER changing the $wgPasswordSalt = false; directive to false. Logging in with the new user into mediawiki does work. Over the httpd authentication the new user can not log in (as well as the old user can’t).

Worked like a charm.

As Paul mentioned, the quotes in $wgWhitelistRead needed changing. Other than that, there was no needto install DB Modules and yet I was able to password protect the wiki for authorised users only. It also prevented anonymous users from creating new accounts.

Kind regards,
Manoj

I didn’t need to create a new cookie, because the UserID cookie is only to be found, when the user is logged in, so I copied some code from include/User.php method loadFromSession. Now you still could log out, but you never need to login, because with each request you’re automatically logged in with your HTTP Auth login data if the UserID cookie isn’t present.

I’m just tidying up my code and may send you the extension later today.

thank you for yozur reply. That’s exactly what I’m trying to do. However MediaWiki seems to provide no user/session data when the UserLoadFromSession hook is called. I thought about just creating an own additional cookie using the UserLoginComplete hook and check this cookie to avoid the redirection loop.

Kind regards,
Götz

thanks for this great tutorial. After I struggled a bit with some configuration settings (different versions of the module and different names of directives, …) I managed to set this up successfully.

But I’m still working on a single sign on. I tried forwarding the login data (I run PHP as module) to the MediaWiki login form but either I get a redirection loop to the main page or when I turn off the redirection I get an error mesage that $wgTitle is empty.
Did anyone who comes by here manage to make MediaWiki use the HTTP Auth data to log in users correctly (as this is no “external authentiocation” the modules which I found didn’t meet my needs).

Kind regards,
Götz

I’m a giant among midgets at my job, where I’ve been setting up an intranet (WinXP, Apache 2+PHP, MediaWiki, MySql, FreeBSD).

Unfortunately, I’ve been having trouble extending Apache by installing modules like mod_auth_mysql, mod_dav, etc. I don’t know how to uncompress a tar.gz with -xsf under windows. Is there an application that does this? I don’t know how to get/make .so plug in files.

It may benefit others to mention the version used. FreeBSD 6.3, Mediawiki 1.11.1, apache-2.2.8, mod_auth_mysql_another-3.0.0_2 (from the ports collection).

This configuration documentation for mod_auth_mysql might also help people : http://modauthmysql.sourceforge.net/CONFIGURE ]]> http://richardkmiller.com/184/password-protecting-mediawiki-with-mod_auth_mysql/comment-page-1#comment-82143 Rob Velseboer Thu, 24 May 2007 08:50:49 +0000 http://www.richardkmiller.com/blog/archives/2006/05/password-protecting-mediawiki-with-mod_auth_mysql#comment-82143 Actually, you can protect Mediawiki against both reading and writing by anonymous users. Put these lines in your LocalSettings.php file to do so: $wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['*']['read'] = false; Now, anonymous users cannot read any pages, except for the ones you explicitly whitelist, like this: $wgWhitelistRead = array( "Special:Userlogin", "-", "MediaWiki:Monobook.css", "Main_Page" ); That line is probably already in your LocalSettings.php, just add pages you want anonymous users to see. If you don't even want them to see your wiki front page, remove "Main_Page" from this list. Visitors will now be asked to log in immediately, even before they get to see your front page. Unfortunately, by default Mediawiki lets users create their own accounts and this would mean that anonymous visitors can just create an account and have all the privileges you didn't want them to have. Protect your wiki against account creation by adding this line to LocalSettings.php: $wgGroupPermissions['*']['createaccount'] = false; Be aware that now legitimate new users cannot create their own accounts either, (but that problem also existed with the mod_auth_mysql approach). There is a way for wiki admin users to create new accounts though: * Go to the Special:Userlogin page (after loging in as an admin) * Click "Create an account" * Fill in the form, uncheck the box "Remember my login on this computer" * Click "by e-mail" The new user gets an e-mail with a generated password (I found out the password I typed in the form was discarded) After logging in for the first time, the new user is asked to choose a new password. Hope this is useful for people who don't have access to the Apache configuration on their site, and also for people who are annoyed by having to log in twice. Actually, you can protect Mediawiki against both reading and writing by anonymous users. Put these lines in your LocalSettings.php file to do so:

$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;

Now, anonymous users cannot read any pages, except for the ones you explicitly whitelist, like this:

$wgWhitelistRead = array( “Special:Userlogin”, “-”, “MediaWiki:Monobook.css”, “Main_Page” );

That line is probably already in your LocalSettings.php, just add pages you want anonymous users to see.
If you don’t even want them to see your wiki front page, remove “Main_Page” from this list.
Visitors will now be asked to log in immediately, even before they get to see your front page.

Unfortunately, by default Mediawiki lets users create their own accounts and this would mean that anonymous visitors can just create an account and have all the privileges you didn’t want them to have.
Protect your wiki against account creation by adding this line to LocalSettings.php:

$wgGroupPermissions['*']['createaccount'] = false;

Be aware that now legitimate new users cannot create their own accounts either, (but that problem also existed with the mod_auth_mysql approach).

There is a way for wiki admin users to create new accounts though:

* Go to the Special:Userlogin page (after loging in as an admin)
* Click “Create an account”
* Fill in the form, uncheck the box “Remember my login on this computer”
* Click “by e-mail”

The new user gets an e-mail with a generated password (I found out the password I typed in the form was discarded)
After logging in for the first time, the new user is asked to choose a new password.

Hope this is useful for people who don’t have access to the Apache configuration on their site, and also for people who are annoyed by having to log in twice.

(sorry, this should be in my previous post, if there was an edit option)

AuthName “This wiki is password protected (make sure the first letter \
of the username is Uppercase)”
AuthGroupFile /dev/null
AuthUserFile /dev/null
AuthMySQLEnable On
AuthMySQLHost localhost
AuthMySQLUser wikiuser
AuthMySQLPassword wikipassword
AuthMySQLDB wunderwikidb
AuthMySQLUserTable user
#AuthMySQLUserCondition “users.status = 1″
AuthMySQLNameField user_name
AuthMySQLPasswordField user_password
AuthMySQLNoPasswd Off
AuthMySQLPwEncryption md5
AuthMySQLAuthoritative On
require valid-user

Now its working
hope someone can use this info ]]> http://richardkmiller.com/184/password-protecting-mediawiki-with-mod_auth_mysql/comment-page-1#comment-53480 Noah Blumenfeld Wed, 21 Mar 2007 15:00:45 +0000 http://www.richardkmiller.com/blog/archives/2006/05/password-protecting-mediawiki-with-mod_auth_mysql#comment-53480 Just wanted to say that this's very useful :) I've used the mysql module to password protect other pages. Just wanted to add something to keep in mind. Since mod_auth_mysql is being used with apache in basic authentication mode, as with any other basic apache auth scheme, it will request your username/password every time you goto the page. Most modern browsers cache username/password for that reason. So keep in mind that if you use this method (as opposed to php sessions or so), if the page is not closed (and/or cache is not purged, depending on browser) - the browser will let anybody else access that page as long as the username/password are in the cache. So if you are using your wiki from a public access computer, keep that in mind. :) I'm currently building a mission critical system and had to work around this problem. Just wanted to say that this’s very useful I’ve used the mysql module to password protect other pages. Just wanted to add something to keep in mind.

Since mod_auth_mysql is being used with apache in basic authentication mode, as with any other basic apache auth scheme, it will request your username/password every time you goto the page. Most modern browsers cache username/password for that reason.

So keep in mind that if you use this method (as opposed to php sessions or so), if the page is not closed (and/or cache is not purged, depending on browser) – the browser will let anybody else access that page as long as the username/password are in the cache.

So if you are using your wiki from a public access computer, keep that in mind.

I’m currently building a mission critical system and had to work around this problem.

Thanks for stopping by! I’m glad you found the post. Gary Thornock was the other Utahn that helped craft this solution.