Last modified: 2011-08-11 18:59:19 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 T31123, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 29123 - Section edit links shown to anon users even if they can't edit
Section edit links shown to anon users even if they can't edit
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-24 15:54 UTC by Ilmari Karonen
Modified: 2011-08-11 18:59 UTC (History)
6 users (show)

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


Attachments

Description Ilmari Karonen 2011-05-24 15:54:17 UTC
Reported on #mediawiki:

<aurimai> Hi! Mediawiki 1.17 at revision 88718, anonymous users see [edit] links, although in LocalSettings.php the option $wgDefaultUserOptions['editsection'] = false; I have not a slightest idea what it can be. It seems to have appeared after I checked out from SVN last time.
<aurimai> I have a private wiki. In order to edit the users have to log in. Anonymous users are still disabled to edit, but they see the [edit] link.
<aurimai> Vyznev, I confirm, there are no [edit] links on talk pages.
<aurimai> Vyznev, $wgUseFileCache is not defined in LocalSettings.php

I also observe similar symptoms on my own wiki, which currently runs r80786; however, in my case, turning off $wgUseFileCache fixes it, so I suspect that there may be two separate bugs involved.  Alas, I'm unable to debug this more thoroughly right now.

Ps. Dupe search turns up the old bug 26458: "Section edit links appear on pages that user does not have right to edit"; it might be possible that the recent regression is related to the same code.
Comment 1 Subfader 2011-05-24 22:07:16 UTC
Are you sure you didn't add $wgDefaultUserOptions['editsection'] = false; AFTER those affected page were cached last time?
Comment 2 Ilmari Karonen 2011-05-25 07:45:50 UTC
$wgDefaultUserOptions is really a red herring -- the section edit links shouldn't be shown to users who can't edit the page anyway.  Still, you may be right that aurimai's report might have been caused by stale cached pages.  In my case, though, I doubt that, as I've had anon editing disabled since pretty much forever.
Comment 3 Rob Lanphier 2011-05-25 21:50:14 UTC
I can't reproduce this using the release from branches/REL1_17, r88842 (which is unchanged since r88444).  I've tried all of these combinations:
1.  $wgGroupPermissions['*']['edit'] = false;
2.  $wgDefaultUserOptions['editsection'] = false;
3.  $wgGroupPermissions['*']['edit'] = false; $wgDefaultUserOptions['editsection'] = false;

In all cases, the [edit] links go away for anonymous users.
Comment 4 Ilmari Karonen 2011-05-27 18:54:38 UTC
Actually, there seems to have been at least one genuine bug in the new parser cache code, which (I think) I fixed in r88988.  This bug caused users with and without section editing enabled to share the same parser cache keys, leading to section edit links being mysteriously shown or not shown to user who shouldn't or should see them.
Comment 5 Antoine "hashar" Musso (WMF) 2011-06-02 13:23:34 UTC
The proposed change in r88988 does not fix anything since the modified code is not deployed in 1.17 or on the live site.
See code review comment on r88988

Reopening bug
Comment 6 Platonides 2011-06-02 19:44:41 UTC
Works for me, too (both trunk and REL1_17).
Maybe he could give us a link to his wiki?
Comment 7 Rob Lanphier 2011-06-02 20:42:01 UTC
Alright, I see the problem.  Here are the settings to reproduce:

1.  Set the following in LocalSettings.php:
$wgUseFileCache = true;
$wgShowIPinHeader = false;
$wgGroupPermissions['*']['edit'] = false;

2.  Log in, and edit a page with edit links on it

3.  View the page anonymously

Expected result:
No edit links

Actual result:
Edit links
Comment 8 Platonides 2011-06-07 22:30:06 UTC
I have readded the fix for bug 14404 in r89706. I think it should have also fixed this. Can you verify?
Comment 9 Platonides 2011-06-19 16:52:57 UTC
I can't reproduce it at r89705. And yes, I seem to have now a working htmlcache, and bypassed the 512 bytes limit of saveToFileCache()
Comment 10 s7eph4n 2011-08-11 12:30:51 UTC
I see this bug on a freshly installed MW 1.17.0.

Both anonymous and logged-in users are affected, i.e. I have tried

 $wgDefaultUserOptions['editsection'] = false;

and I turned off the respective user preference, too. The edit links are shown regardless.

Does not seem to have to do anything with caching either, purged after every change of the settings.

(And for what it's worth, I do not consider this a minor bug.)
Comment 11 s7eph4n 2011-08-11 12:39:06 UTC
Hmm, on second thought this might be a new bug, it does not have anything to do with edit rights. These seem to work well, i.e. no edit rights no edit links.

It's just that setting $wgDefaultUserOptions['editsection'] to whatever value has no effect at all.

New bug?
Comment 12 Mark A. Hershberger 2011-08-11 18:50:54 UTC
yes, new bug. please create one?
Comment 13 s7eph4n 2011-08-11 18:59:19 UTC
Done: Bug 30331.

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


Navigation
Links