Last modified: 2013-10-23 18:17:00 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 T37252, the corresponding Phabricator task for complete and up-to-date bug report information.
First Last Prev Next    This bug is not in your last search results.
Bug 35252 - $wgBlockDisablesLogin - effective on a private wiki?
$wgBlockDisablesLogin - effective on a private wiki?
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
User blocking (Other open bugs)
1.18.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency tree / graph
 
Reported: 2012-03-16 04:42 UTC by Jasper Deng
Modified: 2013-10-23 18:17 UTC (History)
3 users (show)

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

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Jasper Deng 2012-03-16 04:42:37 UTC 
At http://mediawiki.org/wiki/Extension_talk:$wgBlockDisablesLogin, it appears that an anonymous user has found a bug in the software. Apparently, while logins are disabled, read/write access is still granted to a user blocked with this setting set.
Comment 1 Brion Vibber 2012-03-16 05:37:13 UTC 
Do you mean that existing logins remain valid?

... fixed link: https://www.mediawiki.org/wiki/Manual_talk:$wgBlockDisablesLogin
Comment 2 Jasper Deng 2012-03-16 21:51:14 UTC 
No, the user login is denied, but as an anonymous user there is read/write access.
Comment 3 Alexandre Emsenhuber [IAlex] 2012-04-02 06:02:05 UTC 
This is the correct behaviour, that setting doesn't disable anonymous read/write access as stated on the page: https://www.mediawiki.org/wiki/Manual:$wgBlockDisablesLogin
Comment 4 Jasper Deng 2012-04-02 23:25:26 UTC 
No, the behavior apparently is that the user who logs in, after a failed login, gets read/write access ''but where anonymous users shouldn't get it in the first place'', i.e. $wgGroupPermissions['*']['read']=false;.
Comment 5 Nemo 2012-11-24 10:24:48 UTC 
I've tested this in a few ways with my blocked account on internal.wikimedia.org and it works for me.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links