Last modified: 2010-05-15 15:38:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T7122, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 5122 - Login not possible when 'createaccount' set to 'false'
Login not possible when 'createaccount' set to 'false'
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.5.x
All FreeBSD
: Lowest normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 6376 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-27 20:21 UTC by Arnaud Lacombe
Modified: 2010-05-15 15:38 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Arnaud Lacombe 2006-02-27 20:21:33 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;
                        }
Comment 1 Arnaud Lacombe 2006-02-27 20:23:33 UTC
ooups, that's my first bug report here and I didn't find where to attach diff, sorry

regards,

Arnaud 
Comment 2 Rob Church 2006-02-27 20:35:17 UTC
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.
Comment 3 Arnaud Lacombe 2006-02-28 00:33:27 UTC
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.
Comment 4 Brion Vibber 2006-02-28 08:37:38 UTC
If you want it to work, you probably should configure it correctly.
Comment 5 Arnaud Lacombe 2006-02-28 11:13:12 UTC
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
Comment 6 Brion Vibber 2006-02-28 21:17:27 UTC
It's nothing to do with createaccount. It's to do with setting *read* off.
Comment 7 Brion Vibber 2006-02-28 23:58:58 UTC
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.
Comment 8 Brion Vibber 2006-06-19 21:37:00 UTC
*** Bug 6376 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links