Last modified: 2014-02-12 23:35:45 UTC
$wgWhitelistRead allows actions other than reading for a page. This can leak account names on wikis where they're supposed to be private: http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page&action=history http://en.wikipedia.org/w/index.php?title=User_talk:Kirill_Lokshin&oldid=463197526#Quick_question Also, something weird is going on here: http://arbcom.en.wikipedia.org/wiki/Main_Page http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page
Sam, could you take a look at this one?
I'm presuming that the wiki falls under "private"... 'private' => array( 'Main Page', 'Special:Userlogin', 'Special:Userlogout', '-', 'MediaWiki:Monobook.css', 'MediaWiki:Monobook.js' ),
Some of the strange behavior being exhibited here is due to "Main Page" being whitelisted, but on this particular wiki, that page is a redirect (to "Main page").
CC'ing Phillippe as this is happening on arbcomwiki
Thanks, Reedy. Can we un-whitelist the Main page? Understanding that I'm a technical moron, and may not know the full implications of that....
We can remove the main page from the whitelist on wikis that want that. Some private wiki main pages actually contain useful information for the public, so I wouldn't want to just do it on all of them.
When I look at this: http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page&action=history I see "(username removed)" and "(edit summary removed)". Is that because someone took some manual action in this case? I'm going to assume that since this at least has a workaround, this is normal priority. It'd be helpful to have an idea of what the "right" solution is, since it's not obvious to me.
(In reply to comment #7) > I see "(username removed)" and "(edit summary removed)". Is that because > someone took some manual action in this case? Yes. > I'm going to assume that since this at least has a workaround, this is normal > priority. It'd be helpful to have an idea of what the "right" solution is, > since it's not obvious to me. The simple (conceptually, if not in implementation!) solution would be to make $wgWhitelistRead only whitelist reading (and only the current version of a page). I think the weirdness I originally noted with "/w/index.php?title=" vs. "/wiki/" had to do with whether the content (of the redirect target?) was displayed. I assume http://arbcom.en.wikipedia.org/w/index.php?title=Main_Page&diff=next&oldid=1797 was a work-around for that. (There must also be some separate caching going on: the sidebar still looked different for one than the other until I purged the cache for the page.)
(In reply to comment #8) > The simple (conceptually, if not in implementation!) solution would be to make > $wgWhitelistRead only whitelist reading (and only the current version of a > page). I don't know whether that would be acceptable for other private wikis. There may be cases where it's desirable to have version information available for public pages, and presumably it's fairly rare for private wiki users to have secret usernames.
Hi Sam / Tim, Trying to understand what (if anything) needs to happen for this bug. It sounds like Tim doesn't think Emufarmer's suggesting that $wgWhitelistRead only allow reading is desirable, and I would agree. I sounds like the issue that spawned the discussion should have been solved by strong passwords and blocking ip's that attempt to brute force. So sites that really want to keep their usernames secret should be pretty rare. But is this something that we would want to implement as an extension, for sites that want it?
(In reply to comment #10) > I sounds like the issue that spawned > the discussion should have been solved by strong passwords and blocking ip's > that attempt to brute force. We require a captcha for IPs that attempt brute force password guessing. It seems to be effective, and avoids the collateral damage that can happen when shared IPs are blocked.
(In reply to comment #11) > We require a captcha for IPs that attempt brute force password guessing. It > seems to be effective, and avoids the collateral damage that can happen when > shared IPs are blocked. Very cool. I was hoping something like that existed, but hadn't come across it yet. (In reply to comment #8) > The simple (conceptually, if not in implementation!) solution would be to make > $wgWhitelistRead only whitelist reading (and only the current version of a > page). So in response to this recommendation specifically, it sounds like an enhancement that would be nice to have for sites that want some extra security through obscurity. Should we classify this as an enhancement request, and add it to the backlog?
(In reply to comment #12) > So in response to this recommendation specifically, it sounds like an > enhancement that would be nice to have for sites that want some extra security > through obscurity. Should we classify this as an enhancement request, and add > it to the backlog? Yes.
