Last modified: 2010-05-15 15:38:13 UTC
I tried to restrict access to mediawiki in order to disallow read for anonymous. I also wanted to restrict account creation, so I put the following lines in LocalSettings: $wgGroupPermissions['*']['createaccount'] = false; $wgGroupPermissions['*']['read'] = false; $wgGroupPermissions['*']['edit'] = false; As soon as I put those lines, I've been unable to access login page. The following patch allows you to login even if 'createaccount' is set to false. --- ../foo/mediawiki-1.5.6/includes/Title.php 2005-10-30 02:30:44.000000000 +0100 +++ includes/Title.php 2006-02-27 21:07:33.000000000 +0100 @@ -1004,9 +1004,11 @@ global $wgWhitelistRead; /** If anon users can create an account, - they need to reach the login page first! */ - if( $wgUser->isAllowed( 'createaccount' ) - && $this->getNamespace() == NS_SPECIAL + they need to reach the login page first! + Already registered users need also to reach + the login page. + */ + if( $this->getNamespace() == NS_SPECIAL && $this->getText() == 'Userlogin' ) { return true; }
ooups, that's my first bug report here and I didn't find where to attach diff, sorry regards, Arnaud
You use $wgWhitelistRead to allow explicit access to "Main Page", "Special:Userlogin" and "-" and this problem disappears. It's noted well enough in the documentation.
isn't the $wgWhitelistRead method just a workaround ? I mean isn't that quite "stupid" to tell the user to login if *by*default* the login page is not accessible just if 'createaccount=false', whereas if 'createaccount=true' the anonymous user will be granted to create an user and login ? sorry to reopen the bug, but I really find something wrong in the current behaviour.
If you want it to work, you probably should configure it correctly.
Maybe you could try to explaim me why there is such behavior, ie, why the access to the login page is possible or not depending the value of 'createaccount'. If the login page was not accessible for any value of 'createaccount', *there* I would understand the use of white list and so on, but _it's_not_ the case here. ps: what is wrong is my configuration ? is it bad to forbid read & account creation ? ps2: I do not reopen the bug, but I'd to have an answer
It's nothing to do with createaccount. It's to do with setting *read* off.
The problem appears to be that Hashar added a special-case around the whitelist for Special:Userlogin when createaccount is on. This is incorrect, as logins tend to be useful also when createaccount is off, and other useful/important/vital bits like the main page and CSS/JS generators are not special-cased. Probably the special case should be removed as it seems to merely confuse people.
*** Bug 6376 has been marked as a duplicate of this bug. ***
