Page MenuHomePhabricator

Section edit links shown to anon users even if they can't edit
Closed, ResolvedPublic

Description

Reported on MediaWiki-General:

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


Version: unspecified
Severity: minor

Details

Reference
bz29123

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:28 PM
bzimport set Reference to bz29123.
bzimport added a subscriber: Unknown Object (MLST).

Are you sure you didn't add $wgDefaultUserOptions['editsection'] = false; AFTER those affected page were cached last time?

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

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.

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.

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

Works for me, too (both trunk and REL1_17).
Maybe he could give us a link to his wiki?

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;

  1. Log in, and edit a page with edit links on it
  1. View the page anonymously

Expected result:
No edit links

Actual result:
Edit links

I have readded the fix for bug 14404 in r89706. I think it should have also fixed this. Can you verify?

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()

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

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?