Login not possible when 'createaccount' set to 'false'
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	• bzimport
	Feb 27 2006, 8:21 PM

Description

Author: wikimedia

Description:
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;
}

Version: 1.5.x
Severity: normal
OS: FreeBSD

Details

Reference: bz5122

Event Timeline

• bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:08 PM

• bzimport added a project: MediaWiki-Page-editing.

• bzimport set Reference to bz5122.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Feb 27 2006, 8:21 PM

wikimedia wrote:

ooups, that's my first bug report here and I didn't find where to attach diff, sorry

regards,

Arnaud

robchur wrote:

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.

wikimedia wrote:

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.

wikimedia wrote:

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. ***

Login not possible when 'createaccount' set to 'false'Closed, InvalidPublicActions

Description

Details

Event Timeline

Login not possible when 'createaccount' set to 'false'
Closed, InvalidPublic
Actions