Cairo (by default) had this preferences evaluation order:
- system level (
TWiki.TWikiPreferences
)
- site level (
Main.TWikiPreferences
)
- web level (
WebPreferencs
)
- topic level
- user level (
Main.UserHomeTopic
)
It could be changed with the TOPICOVERRIDESUSER setting to this:
- system level
- site level
- web level
- user level
- topic level
Dakar seems to have this order:
- system level
- site level
- user level
- web level
- 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.
- With either ordering, a user could defeat permissions for any web if FINALPREFERENCES didn't include ALLOW/DENY variable names.
- 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