Item2394: System.SitePermissions improvement: implement EXPAND macro

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 |
| %USERSWEB% | %WEBPREFERENCE{"DENYWEBVIEW" web="%USERSWEB%"}% | %WEBPREFERENCE{"ALLOWWEBVIEW" web="%USERSWEB%"}% |

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:

%EXPAND{"MYPREFERENCE" topic="%OTHERTOPIC%"}%

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:

Web	Sitemap	VIEW		CHANGE		RENAME
	Listed	DENY	ALLOW	DENY	ALLOW	DENY	ALLOW
About	on			WikiGuest
Community	on			WikiGuest
Community.Developers	on			WikiGuest
Development	on			WikiGuest
Download	on			WikiGuest
Extensions	on			WikiGuest
Extensions.Archived	on			WikiGuest
Extensions.Testing	on			WikiGuest
Home	on			WikiGuest
Main	on			WikiGuest
Support	on			WikiGuest
Support.ClientSupport	on			WikiGuest
Support.Question922	on			WikiGuest
System	on			WikiGuest
Tasks	on			WikiGuest
Tasks.Testcases	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