• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Cairo (by default) had this preferences evaluation order:

  1. system level (TWiki.TWikiPreferences)
  2. site level (Main.TWikiPreferences)
  3. web level (WebPreferencs)
  4. topic level
  5. user level (Main.UserHomeTopic)

It could be changed with the TOPICOVERRIDESUSER setting to this:

  1. system level
  2. site level
  3. web level
  4. user level
  5. topic level

Dakar seems to have this order:

  1. system level
  2. site level
  3. user level
  4. web level
  5. topic level

You can verify this with a TESTPREF setting in your home topic and WebPreferences, and by using %TESTPREF% in any topic.

-- PTh

Correct. This is by design, and is clearly described in DakarReleaseNotes#Preferences

CC

Fair enough, I do not anticipate that this change casues problems with TWiki applications.

What was the reasoning to change the spec?

-- PTh

Mainly for hierarchical webs (lower level webs inherit prefs from their parent webs, as you would expect).

CC

I do not see the connection of hierarchical webs and moving user pref between site pref and web pref.

One drawback of the spec change: The current behaviour prevents users from adding a TWikiForm to a templatetopic if the user has no permission to edit the web prefs. I see users add a WEBFORMS setting in their twiki.org user home topic once in a while to experiment with forms in the Sandbox web on twiki.org.

-- PTh

Actually, the hierarchical webs mods (all in TWiki::Prefs::pushWebPreferences) happened independently of this ordering. Introduction of user prefs could come before or after pushWebPreferences.

This prompted me to think a bit more about the use of FINALPREFERENCES. Some hierarchical web permission configurations rely on FINALPREFERENCES variable not being set by higher level webs in order to set up a scenario which disallows editing in higher level webs while opening up edit or view privileges in a lower level web.

The preference in most hierarchical webs to not include permissions variables in FINALPREFERENCES opens up some security holes.

  1. With either ordering, a user could defeat permissions for any web if FINALPREFERENCES didn't include ALLOW/DENY variable names.
  2. In the current ordering a user could set ALLOW/DENY variables and include those variable names in FINALPREFERENCES in their user topic in order to defeat local web or topic preferences.

So, I'd propose to add a heuristic to the preferences engine that causes ALLOW/DENYWEB settings in the user topic to be applied only to the user topic, as well as any of the like in a FINALPREFERENCES setting in the user topic. This will allow the user some flexibility while protecting the site at the same time.

-- PN

ItemTemplate
Summary Reversed preferences eval order for user level and web level
ReportedBy PeterThoeny
Codebase

SVN Range Fri, 30 Dec 2005 build 8037
AppliesTo Engine
Component

Priority Normal
CurrentState No Action Required
WaitingFor

Checkins 8050
TargetRelease n/a
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r8 - 2006-03-26 - PeterNixon
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback