Page MenuHomePhabricator

Cannot edit pages where permissions are inferred from other user groups
Closed, ResolvedPublic


I cannot edit the following page using MobileFrontend:

This is despite I'm logged in as Amire80 and I have sysop rights.

This may have something to with the fact that the page is protected to autopatrolled users, a level that is special to the Hebrew Wikipedia, but it may also happen for an entirely different reason.

(And I'm sorry about the very long and ugly URL.)

Version: unspecified
Severity: normal

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:57 AM
bzimport set Reference to bz72877.
bzimport added a subscriber: Unknown Object (MLST).

bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card

You seem to be right about protection. Only authors seem to be able to edit the page.

Amir can you paste

mw.mobileFrontend.getCurrentPage().isEditable( mw.user).done( function(r) { console.log(r); });
mw.user.getGroups().done( function(a) { console.log( a ); } );
mw.config.get( 'wgRestrictionEdit', [] );

into your console for this page and report back what it says?
I think this will give the information needed to make this bug actionable.

mw.mobileFrontend.getCurrentPage().isEditable( mw.user).done( function(r) { console.log(r); });

Object { resolve: .Deferred/</deferred[tuple[0]](), resolveWith: jQuery.Callbacks/self.fireWith(), reject: .Deferred/</deferred[tuple[0]](), rejectWith: jQuery.Callbacks/self.fireWith(), notify: .Deferred/</deferred[tuple[0]](), notifyWith: jQuery.Callbacks/self.fireWith(), state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), 4 more… }

mw.user.getGroups().done( function(a) { console.log( a ); } );

Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }
Array [ "epcampus", "epcoordinator", "epinstructor", "eponline", "sysop", "*", "user", "autoconfirmed" ]

mw.config.get( 'wgRestrictionEdit', [] );

Array [ "autopatrol" ]

Okay, I can replicate it

According to your permissions you fall into the [ "epcampus", "epcoordinator", "epinstructor", "eponline", "sysop", "*", "user", "autoconfirmed" ] groups

The page is restricted so that only the autopatrol group can edit it a group which according to above you are not in.

Why does autopatrol not show up in your groups?

I assume 'sysop' is like a wildcard? It should probably either show up in 'wgRestrictionEdit'...

Smells like an issue in core...

Hmm, this seems to be a problem how we check, if your group is allowed to edit this page. While desktop checks the rights of your impliziet and explicit user groups, we are using the build in mediawiki routine User.getGroups to get the list of groups you actually belong to. The problem is, that this list includes only explicit groups, but implicit groups (e.g. that you're autoconfirmed when you're in sysop group) are missing :/

Jdlrobson set Security to None.

Mm.. how can we get implied groups?

Jdlrobson renamed this task from cannot edit a page through MobileFrontend despite being logged-in and having appropriate permissions to Cannot edit pages where permissions are inferred from other user groups.Dec 9 2014, 11:37 PM

I will take a look, maybe we should patch this in core :)

Sorry, my first thought was false. getGroups already returns all effective groups for the user, which is, what we want. But now i have seen the following:
We get the restrictions for a page from our mobileview api module, which adds the protection levels here:

Title::getRestrictions() returns an array of _rights_ the user needs to edit this page (in case of the example page above it is autopatrol, see

In Page.js we check the user _groups_ against the returned user _rights_ to see, if the user is allowed to edit the page:

This results in the following check (as an example):

if ( $.inArray( sysop, autopatrol ) > -1 ) {

(and for all other groups the user belongs to). That's a real problem: It will work until we use the standard groups and restriction levels (where the group name and the right is the same, see [[$wgRestrictionLevels]]), but not, if there are additional groups like on hewiki. If @Amire80 is able to test it: it will still not work, if you give yourself the user group "autopatrolled", because the group name is different from the right name (autopatrolled <> autopatrol).

I'm not sure, but this looks like a small security issue, too, because it's not the intended behavior of wgRestrictionLevels (e.g. what, if you give a group the name "autopatrol" but not the right autopatrol, they can edit it in MF, but not on desktop).

Change 178793 had a related patch set uploaded (by Florianschmidtwelzow):
Use user rights to check, if the user can edit page


Matanya changed Security from None to Software security bug.Dec 11 2014, 3:29 PM
Restricted Application changed the visibility from "Public (No Login Required)" to "Custom Policy". · View Herald TranscriptDec 11 2014, 3:29 PM
Restricted Application changed the edit policy from "All Users" to "Custom Policy". · View Herald Transcript
Restricted Application added a project: acl*security. · View Herald Transcript
Amire80 changed Security from Software security bug to None.Dec 11 2014, 9:53 PM
Legoktm changed the visibility from "Custom Policy" to "Public (No Login Required)".
Legoktm changed the edit policy from "Custom Policy" to "All Users".

Change 178793 merged by jenkins-bot:
Let PHP check, if the user can edit a page or not

@Amire80: This fix should go out today. Can you confirm that the fix works?