You are here: Foswiki>Tasks Web>Item2394 (07 Nov 2010, PaulHarvey)Edit Attach

Item2394: System.SitePermissions improvement: implement EXPAND macro

Priority: Enhancement
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Reported By: SvenDowideit
Waiting For:
Last Change By: PaulHarvey
SitePermissions has been implemented using a SEARCH - which does not take the preferences heirarchy, nor cfg{AuthScripts} into consideration, thus giving a false view into what can be a drastically important thing - the privacy and access control of data.

like the GROUPS tag, this needs to be implemented as a rendering of the actual internal view of the truth.

-- SvenDowideit - 22 Nov 2009

I think we can live with this in 1.0.8 so I assign this to minor target release (ie trunk)

-- KennethLavrsen - 25 Nov 2009

Personally I have never been convinced of the value of this topic, but who am I to say. So, what are the requirements?

SitePermissions enumerates per web. In each web, it shows the DENYWEB and ALLOWWEB settings for that web. The values used by the access checking code can be determined using $meta->getPreference() where $meta is a web object (known in the code as a "web preference". So a table can be built based on the DENY/ALLOW settings for each web, thus:
| *Web* | *View* ||
|       | DENY | ALLOW |
There is a semantic difference between "not set" and "set to the empty string" that has to be catered for. The provision of a default on the WEBPREFERENCE tag would do the job.

Since access controls is the only place where web preferences are actually used (as against the more typical topic preferences returned by the traditional %MACRO% syntax) then I think this explicit macro expansion mechanism should suffice.

Note that another, perhaps more general, mechanism would be an "expand this macro in another context" macro. This would return the value of a macro as it would be if the current topic (web) were something else. For example, if I'm editing topic "ThisTopic" and I write %EXPAND{"FLURB" topic="ThatTopic"}% it would return the value of %FLURB as if "ThatTopic" were the current topic. topic would default to the current web.topic, so this makes this doubly interesting, since it supports delayed expansion. Other parameters could be passed by name on to the expansion of the macro, so %EXPAND{"MACRO" topic="Item2394" _DEFAULT="parameter" a="b"}% would be equivalent to %MACRO{"parameter" a="b"}%

EXPAND{"macroname" topic="topictoexpandin" ...}%

Expands macroname to the value it would have when the topic topictoexpandin was viewed. The viewer must have VIEW access to topictoexpandin for this to work.

%EXPAND can be useful when you want to pick up the value of macros defined in another topic. For example, you might want to define a set of preferences in one topic, but pick up their value in another topic (this is very useful when building reusable applications). In this case you can write:
   * Set MYPREFERENCE = value
in "ThisTopic" and then, in "ThatTopic", write:
%EXPAND{"MYPREFERENCE" topic="ThatTopic"}%
Since ThatTopic can itself be a macro, we can write:
which lets us select which other topic to get the preference value from.

Note that %EXPAND is not very efficient, and should be used sparingly.

This is interesting enough that I'm raising it as a feature request.

-- CrawfordCurrie - 20 Jan 2010

If viewing on trunk, where EXPAND is available, the site permissions now looks like this:

Preferences Home About on     WikiGuest      
Preferences Home Community on     WikiGuest      
Preferences Home Community.Developers on     WikiGuest      
Preferences Home Development on     WikiGuest      
Preferences Home Download on     WikiGuest      
Preferences Home Extensions on     WikiGuest      
Preferences Home Extensions.Archived on     WikiGuest      
Preferences Home Extensions.Testing on     WikiGuest      
Preferences Home Home on     WikiGuest      
Preferences Home Main on     WikiGuest      
Preferences Home Support on     WikiGuest      
Preferences Home Support.ClientSupport on     WikiGuest      
Preferences Home Support.Question922 on     WikiGuest      
Preferences Home System on     WikiGuest      
Preferences Home Tasks on     WikiGuest      
Preferences Home Tasks.Testcases on     WikiGuest      
Preferences Home Trash.MiguelSandbox       WikiGuest      
Preferences Home Trash.NC on     WikiGuest      
Preferences Home Trash.PoojaBedur on     WikiGuest      
Preferences Home Trash.StefanKrüger on     WikiGuest      
Preferences Home Trash.Subweb on     WikiGuest      

-- CrawfordCurrie - 20 Jan 2010

I don't think this is a correct solution to the issue. It does not show the internal representation of the ACL's, rather it presumes that the Setting are the only used mechanism, and in the process doesn't interpret the result of mixing ALLOW and DENY's etc.

not only does that mean we have to re implement this completely when someone adds out of band ACL's, but we still force the poor user to try to figure out what a weird combination of ACL's actually results in.

also, it does not expand groups, leading to more confusions.

I'm willing to agree that the sitepermissions output is no longer incorrect, but it still remains mostly harmful.

-- SvenDowideit - 21 Jan 2010

Very true.

Not sure about expanding groups. This easily explodes.

However, the way we currently interface ACL's doesn't seem to allow a scalable solution. The only way we deal with ACL's atm is to checkAccessPermissions(user, location) = true/false. However, what we need here is getACLs(location) = list-of-users. That's expensive to compute the way we store ACLs. WebPermissionsPlugin comes closest to implement such a function. However, it seems broken for the similar reasons Sven provided: it does not resolve mixtures of DENY and ALLOW lists - it simply lists the ALLOW and DENY preferences. I came across the need of an getACLs() for SolrPlugin to add ACLs while indexing a document. The current approach in SolrPlugin isn't scaling either as it reuses checkAccessPermissions() in a quite moron way. Anything else would have to reimplement the internals of checkAccessPermissions() in a redundant way. Other CMSes store node access in a proper SQL table ... which would allow to harvest ACLs easily (see drupal).

-- MichaelDaum - 21 Jan 2010

The EXPAND macro was added some time ago, so removed the WaitingFor and flipped status back to Confirmed

-- CrawfordCurrie - 29 Mar 2010

In the interests of removing a release blocker, is there something I could do with guidance from others here?

I would be happy to work on a new macro even if it's just a spec, but that sounds like a feature request like QueryAccessControls.

Added you all to WaitingFor

-- PaulHarvey - 01 Jul 2010

I think that this is not solvable in the scope of foswiki 1.1 as a real solution would need deeper changes than just a new macro. SitePermissions have been wrong for quite a while now. Getting 1.1 out now is more important than fixing every remaining bug we find now. Specifically this one is a more structural problem in the handling of ACLs internal, so quite an essential and fragile thing to tinker around with.

Lowering it to Normal.

-- MichaelDaum - 02 Jul 2010

I agree it's not solvable in a 1.1 timeframe, but should definitely be looked at for 2.0

-- CrawfordCurrie - 08 Jul 2010

We have useful work to release in 1.1, however, so I re-titled/marked-as-enhancement for the VarEXPAND macro to be mentioned in the release notes.

Continued at Item9276

-- PaulHarvey - 08 Jul 2010

ItemTemplate edit

Summary SitePermissions improvement: implement EXPAND macro
ReportedBy SvenDowideit
Codebase 1.0.7, trunk
SVN Range Foswiki-1.0.7, Sun, 20 Sep 2009, build 5061
AppliesTo Engine
Priority Enhancement
CurrentState Closed
Checkins distro:2d8233cbb808 distro:3090a051a2ef distro:b388123c278d
TargetRelease minor
ReleasedIn 1.1.0
Topic revision: r16 - 07 Nov 2010, PaulHarvey
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