Item11578: groupAllowsChange returns true when 'none' is set as the mapping manager

pencil
Priority: Urgent
Current State: Closed
Released In: 1.2.0
Target Release: minor
Applies To: Engine
Component: FoswikiUsers
Branches: trunk
Reported By: GeorgeClark
Waiting For:
Last Change By: CrawfordCurrie
Users.pm sets the mapper to TopicUserMapping if the mapper is set to 'none.

This results in the %GROUPINFO macro, format=$allowschange returning true even though groups cannot be modified.

This appears to have existed pre-Foswiki.

-- GeorgeClark - 28 Feb 2012

Also, it returns true even if no user is logged in. VarGROUPINFO documents $allowschange as "$allowschange returns 0 (false) or 1 (true) if that group can be modified by the current user."

So the connection to the underlying mapper is wrong, as is the authorization check.

-- GeorgeClark - 28 Feb 2012

It gets worse. Users.pm seems to suggest that groupAllowsChange API is used to return whether or not the group itself allows change. However GROUPINFO calls groupAllowsChange for each member of the group, calling the API for each user (or group) in the group.

The AdminGroup by default, has a single permanent user - AdminUser. Calling GROUPINFO{"AdminGroup" format="$allowschange"} opens an iterator which returns a single member. It then calls groupAllowsChange for that topic -.BaseUserMapping_333. TopicUserMapper gets control and returns true - even as WikiGuest - no user logged in.

I think that the issue is topic BaseUserMapping_333 is not a valid topic, the Main web doesn't restrict change. So Web permissions are applied.

We are also left with a bit of a hole in that there is no way to determine if the Group itself allows change. We can't check topic permissions, because the group might be implemented in a mapper that doesn't use topics.

Possible solution:

  • Resolve the inheritance issue for groupAllowsChange
    • If Mapper is 'none' it should not assume that TopicUserMapper applies
  • BaseUserMapping_* users should not make it into the TopicUserMapper code.
  • GROUPINFO needs a parameter to request attributes of the group itself instead of group members
    • Add "none" argument for show. show="none" cause GROUPINFO to only return information about the group itself and not iterate the members.
  • Need to better define groupAllowsChange and groupAllowsView when called for a User type group member. What about for mappers where the user does not exist in topic form.
  • Foswiki::UserMapping should throw errors if the mapper doesn't implement addUserToGroup or removeUserFromGroup

This is beginning to sound like a feature proposal, but it's really broken.

-- GeorgeClark - 28 Feb 2012

This does not predate Foswiki; GROUPINFO was introduced by me in Item2154. the allowsChange code was by Sven in Item2387.

By my reading, groupAllowsChange is working correctly. However, as you say, the documentation states that:

"$allowschange returns 0 (false) or 1 (true) if that group can be modified by the current user."

This documentation is incorrect. It should read:

"$allowschange returns 0 (false) or 1 (true) if that group can be modified by the *user or group being shown."

AdminGroup will always able to modify itself - it's the Admin group - so any GROUPINFO on that group will show ALLOWSCHANGE for all members.

-- CrawfordCurrie - 10 Mar 2014

 

ItemTemplate edit

Summary groupAllowsChange returns true when 'none' is set as the mapping manager
ReportedBy GeorgeClark
Codebase 1.1.4, trunk
SVN Range
AppliesTo Engine
Component FoswikiUsers
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:ec60d80b1951
TargetRelease minor
ReleasedIn 1.2.0
CheckinsOnBranches trunk
trunkCheckins distro:ec60d80b1951
Release01x01Checkins
Topic revision: r3 - 10 Mar 2014, CrawfordCurrie - This page was cached on 14 May 2020 - 11:02.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy