Tags:
access_control1Add my vote for this tag discussion1Add my vote for this tag create new tag
, view all tags

Access Controls and Preferences

There is considerable confusion regarding the relationship between TWiki Access Controls and TWiki Variables.

TWiki Access Controls are used by setting the values of TWiki Variables. However the rules for determining how access is controlled are totally different to the rules used when determining their value as TWiki Variables.

The User View

From the user view, TWiki access controls are specially named TWiki Variables that can be set to define access control levels. They are set like this:

  • Set ALLOWWEBCHANGE = Main.RobbieRobot, Main.DemolishedMan

If a user outputs the value of this variable, they should see the TWiki Variable Value of this setting. For example,

%ALLOWWEBCHANGE% =

Unfortunately this is not the value of this setting for access control purposes.

As described in TWikiVariables, you can think of preferences as a stack. Each "context" is a level in the stack. So, for example, let's say you are in the middle of rendering a topic. Your mental image of the stack will look like this:

Global --- Site --- User --- Web --- Subweb --- Topic --- Plugin --- Session
  0         1        2        3        4          5          6          7

The user view of preferences is that if a setting of a pref is not found at the "session" level 7, then it will be looked up at the "plugin" level 6, and then the topic level 5, and so on down the stack.

Access controls are rather different. The value of access controls is determined by only looking at parts of the stack.

Global --- Site --- User --- Web --- Subweb --- Topic --- Plugin --- Session
  0         1        2        3        4          5          6          7
                           |------ Web -----| |- Topic -|

For access controls, when working out the value of ALLOWWEBCHANGE, only the "Web" portion of the stack is looked at. When working out the value of ALLOWTOPICCHANGE only the "Topic" portion of the stack is looked at.

The Technical Details

You may expect that if a setting of a pref is not found at the "session" level 7, then it will be looked up at the "plugin" level 6, and then the topic level 5, and so on down the stack.

However thats not actually how it works. There's a number of dirty tricks in play here.

  1. Each stack frame (known as a "PrefsCache" in the code) actually inherits the settings of every frame below it in the stack. When a preference is looked up, it is a single lookup at that stack level; there is no chaining down the stack to find the value. "Final" preferences simply cause the inherited value of a preference to overwrite the local value at each higher level.
  2. Preferences at each level are divided into local and inherited preferences. Inherited preferences include all the values inherited from lower levels of the stack. Local preferences are the preferences set at that level only. So, when a new frame is pushed onto the stack, its inherited values are composed from the local and inherited values from the frame below it, and its local values come from the context.
  3. Each frame is strongly typed. A frame is given a type from the set DEFAULT, SITE, USER, SESSION, WEB, TOPIC or PLUGIN.

Now, clearly, we can reference individual frames in this stack. We can also choose to access only local or inherited values at that level, or both. Complicated, innit?

To make it even more complicated, Prefs.pm only provides the following entry points:

  1. getPreferencesValue - looks up the the local and inherited values in the frame at the top of the stack
  2. getWebPreferencesValue - looks up the local preferences in the WEB-type frame belonging to the named web, and values inherited from parent webs, only.
  3. getTopicPreferencesValue - looks up the preferences coming from the TOPIC level, without reference to any other frame.

Now, access controls only use entry points 2 and 3. So a web access control setting finalised in a parent web will be inherited and finalised for a subweb, but finalising the same setting in the global preferences will have no effect. Finalising a topic access control setting at the web level has no effect on the topic level. Session level cannot override topic or web level.

Phew! Now you know as much as me.

-- Contributors: CrawfordCurrie

Discussion

IMHO this once again highlights how essential it is that we take access controls out of band. The confusion with preferences totally does my head in.

-- CrawfordCurrie - 19 May 2006

Many thanks for documenting this structures. I dared to add the user preferences, because that's what confused me in the beginning: In my home topic, I can override site preferences, but not web preferences. Now I know that this hierarchy is necessary if one wants to define applications in a separate web, with special settings e.g. for EDITBOXHEIGHT, without being disturbed by user preferences.

I am not so sure whether this highlights the necessity to take access controls out of band, though.

-- HaraldJoerg - 19 May 2006

The complexity of the "Access Control as Preferences" is what highlights it. Access Control, albeit being Preferences, are treated in a way special enough to confuse the weary.

-- RafaelAlvarez - 19 May 2006

"I am not so sure whether this highlights the necessity to take access controls out of band, though." That's part of the problem: too damn confusing!

-- MeredithLesly - 19 May 2006

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2006-05-19 - MeredithLesly
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.