Item8380: FLEXWEBLIST is not tracking AccessControl rules

Priority: Normal
Current State: No Action Required
Released In: n/a
Target Release:
Applies To: Extension
Component: FlexWebListPlugin
Reported By: Foswiki:Main.KenMalsky
Waiting For:
Last Change By: MichaelDaum
I'm trying to restrict access to some webs using DENYWEBVIEW, ALLOWWEBVIEW, DENYWEBCHANGE & ALLOWWEBCHANGE. The actual read/write access seems to work just fine. However, I'm using NatSkin with the "web buttons" on, and I would expect buttons to appear for each web to which the logged in user has read access. My end-users would get lost without links to the top of each webs.

Admin users get all the web buttons. Non-admins get only Main which is not assumed to be public in the call from SiteButtons

Is there something odd or am I missing something?

-- KenMalsky - 07 Jan 2010

The problem appears to be with the FLEXWEBLIST{} macro (unrelated to NatSkin). Calling FLEXWEBLIST{} (not argument), the behavior is that for a member of AdminGroup this lists all of the webs, while for a non-admin the list includes only the current web, Main, System, Sandbox & Trash. This same non-admin can view and change topics in a few other webs that are not listed.

-- KenMalsky - 20 Jan 2010

Hmm... WEBLIST gives the same results...

-- KenMalsky - 20 Jan 2010

I'm confused about what the problem is. I also use FlexWebListPlugin. It seems to list webs to the logged-in user based on whether they have WEBVIEW access to particular webs.

If there are individual topics in webs they don't have access to, FlexWebListPlugin won't pick that up. It seems to only check WEBVIEW permissions. It would be a very CPU intensive operation for FLEXWEBLIST to scan every topic to see if topic level permissions might give the logged-in user view permission despite the WEBVIEW policy.

-- PaulHarvey - 20 Jan 2010

The problem is that, for me, FlexWebListPlugin is not listing webs to the logged-in user based on whether they have WEBVIEW access to particular webs. The WEBVIEW controls are working correctly (i.e. limiting view access to specific webs). However, the web names are not appearing in the list. Something is obviously wrong with my install, but I have no idea what it could be.

-- KenMalsky - 21 Jan 2010

A little more info after further experiments: In the System web, SiteMap, AccessControl and SitePermissions list all of the webs correctly and track read permission correctly. However, the FLEXWEBLIST and WEBLIST macro (and therefore SiteButtons) produce one of two results: (1) for WikiAdmins, they list all webs and subwebs (2) for everyone else, they list Main, System, Sandbox and the web currently being displayed. ACL itself seems to be working fine.

Also, bin/search searches all public webs correctly, and it tracks the read permissions of the current user as it should. bin/natsearch does not. It follows FLEXWEBLIST and searches only System, Main, Sandbox and the current web.

-- KenMalsky - 26 Jan 2010

Could you do a little snippet of your web hierarchy and whether the web can be VIEWed by the "normal" user?

My "private" webs are usually a sub-web of a public one, like so:
  • Sandbox (public)
  • Main (public)
  • System (public)
  • Project1 (public)
    • Private1 (private)

Whereas I don't have anything like this:
  • Sandbox (public)
  • Main (public)
  • System (public)
  • Project1 (private)
    • Public1 (public)

I have not checked that the "Public1" web is listed by FlexWebListPlugin. Is this what you have? A public subweb inside a private parent web?

-- PaulHarvey - 26 Jan 2010

Sorry for the slow reply. I am restricting WikiGuest from viewing all webs (except System), so none of them are truly public. The text below is copied to each web's WebPreferences topic with an appropriate group substituted for <PermissionGroup> .

      * Set DENYWEBVIEW = Main.WikiGuest
      * Set ALLOWWEBVIEW = PermissionGroup
      * Set DENYWEBCHANGE = Main.WikiGuest
      * Set ALLOWWEBCHANGE = PermissionGroup
      * Set ALLOWWEBRENAME = Main.AdminGroup

For the "public" webs (including Main and Sandbox), <PermissionGroup> is replaced with "Main.AuthenticatedUserGroup" which is everyone registered. In "private" webs, it is replaced with "Main.ManagerGroup" or "Main.FinanceGroup" or whatever. There is one instance of a sub-web that has permissions that are a superset of the parent web, but the ACL mechanism itself is working fine. In that case, the sub-web button appears as a top level web button when viewing a topic in that web, but the button disappears when viewing other webs. The permissions are all set as FINAL in WebPreferences for all webs except when a sub-web has a difference ACL. Again, access for viewing/modifying works as expected. Only the list of webs is wrong.

BTW: The workaround hack is to change the 6th line in the macro call in System.SiteButtons to:

webs="%USERSWEB%,Project1,Project2,Project3, public, %SYSTEMWEB%"

This is OK for most users. All managers are part of AdminGroup so they can see everything (obviously suboptimal). People with access in between have links on their home page to the webs that don't have buttons (major kludge). Here's the basic layout:

  • Project1 (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = AuthenticatedUserGroup)
    • Project1-1 (inherited)
  • Finance (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = ManagerGroup)
    • Bills (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = BillingGroup)
    • Taxes (inherited)
    • Accounts (inherited)
  • HR (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = ManagerGroup)
    • Benefits (inherited)
    • Payroll (inherited)
  • Project2 (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = AuthenticatedUserGroup)
  • Project3 (DENYWEBVIEW = WikiGuest, ALLOWWEBVIEW = AuthenticatedUserGroup)

In the System web, ALLOWWEBCHANGE = ALLOWWEBRENAME = AdminGroup. No other permissions are set.

-- KenMalsky - 06 Feb 2010

I've tried making all the web purely public. I've played with granting view and change permission at various levels of the ACL hierarchy, but the result is always the same. Permissions work, but FLEXWEBLIST doesn't track it. The only time it is correct is when an admin logs in.

Here's something interesting, though. I have another wiki running Foswiki-1.0.6, and it's working perfectly there. They have most of the same extensions installed. I can't figure out what the difference is.

-- KenMalsky - 10 Feb 2010

Yikes, I'm seeing the same problem.

-- PaulHarvey - 29 Jun 2011

FlexWebListPlugin is using the same API as WEBLIST to get the list of webs. Still, I have problems to reproduce the issue. I did a plain %FLEXWEBLIST% and get a _considerably smaller list of webs when not logged in. I am testing on a foswiki/trunk.

-- MichaelDaum - 26 Aug 2011

Can't see where the problem is. Reporter mentions WEBLIST behaving the same way. So I assume this is a configuration problem of permissions rather than a plugin problem. Iff there is an issue, it has to be in both, WEBLIST and FLEXWEBLIST as they use the same internal API. Closing for now.

-- MichaelDaum - 10 Jan 2012

ItemTemplate edit

Summary FLEXWEBLIST is not tracking AccessControl rules
ReportedBy Foswiki:Main.KenMalsky
Codebase 1.0.7
SVN Range
AppliesTo Extension
Component FlexWebListPlugin
Priority Normal
CurrentState No Action Required
ReleasedIn n/a
Topic revision: r11 - 10 Jan 2012, MichaelDaum - This page was cached on 24 Nov 2020 - 07:12.

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