Tags:
create new tag
, view all tags

Feature Proposals » Protect Predefined Variables

Summary

Current State: Developer: Reason: Date: Concerns By: Bug Tracking: Proposed For:
MergedToCore HideyoImazu AcceptedBy7DayFeedbackPeriod 2013-03-25   TWikibug:Item7393 KampalaRelease

Edit Form

TopicSummary:
CurrentState:
CommittedDeveloper:
ReasonForDecision:
DateOfCommitment:   Format: YYYY-MM-DD
ConcernRaisedBy:
BugTracking:
OutstandingIssues:
RelatedTopics:
InterestedParties:
ProposedFor:
TWikiContributors:
 

Motivation

You can wreak havoc by redefining predefined variables (providing functions rather than set by "* Set = VARIABLE = VALUE") such as SCRIPTURL. So far, unless a predefined variable is listed in FINALPREFERENCES, it can be overridden by setting a value to it.

Description and Documentation

Predefined variables need to be able to be protected from being overridden for the following reasons.

  • A user may do that without knowing the consequences
  • If DynamicAccessControl is in effect, redefining predefined variables may flip the result

To this end, the OVERRIDABLEPREDEFINEDVARIABLES preferences variable will be introduced. It will have a comma separated list of predefined variables which can be overridden. There is a special value "all", which is the default value and means all predefined variables are overridable. As you can imagine, the value "all" being the default value is for compatibility with previous releases of TWiki.

Examples

You will see the following line on TWikiPreferences so that any predefined variable can be overridden, which is for compatibility with prior releases of TWiki.

   * Set OVERRIDABLEPREDEFINEDVARIABLES = all

You may override it on TWikiPreferences as follows so that no predefined variables can be overridden.

   * Set OVERRIDABLEPREDEFINEDVARIABLES =

A WebPreferences may further override it as follows so that DATE and LANGUAGE can be overridden, but nothing else.

   * Set OVERRIDABLEPREDEFINEDVARIABLES = DATE, LANGUAGE

Implementation

%OVERRIDABLEPREDEFINEDVARIABLES% will be referred to at the beginning of TWiki::_expandTagOnTopicRendering()

  • If it's 'all' or it contains the variable being processed, the function will work in the same manner as now
  • Otherwise, the function checks if the predefined variable of the specified name exists. If it does, returns the value
  • Otherwise, handle it as a preferences variable

Rationale of the implementation

Initially, I thought that the goal can be achieved by finalizing preference values automatically. But then I realized that plug-ins are enabled after preferences are read, which means that it's not possible to finalize predefined variables when preferences are read.

So it's simpler and more practical to prevent predefined variable override when a variable is looked up, which is in the =TWiki::_expandTagOnTopicRendering().

Implementation

-- Contributors: Hideyo Imazu - 2013-03-25

Discussion

Makes sense. Do you meant to add more system variables to the FINALPREFERENCES? TWiki.TWikiPreferences currently lists just WEB, TOPIC

-- Peter Thoeny - 2013-03-25

For flexibility, putting them on TWiki.TWikiPreferences and Main.TWikiPreferences is fine. For efficiency, finalizing them automatically seems better. I'm leaning toward the latter. What do you think?

-- Hideyo Imazu - 2013-03-26

Fine my me. I think we should look at which ones need to be finalized, and which ones are better not finalized to account for corner cases.

-- Peter Thoeny - 2013-03-26

I accidentally reset %TOPIC% once. I heartily endorse this feature.

-- Vicki Brown - 2013-05-16

Discussed at JerusalemReleaseMeeting2013x05x16:

  • Recommend to hard code in array and/or use .cfg, better performance than using FINALPREFERENCES

-- Peter Thoeny - 2013-05-17

I've realized that it's clearer to regard this as a function tag issue rather than predefined variables in general. So I've change the topic summary as well as the topic name.

-- Hideyo Imazu - 2013-08-20

Sorry for flip-flopping but I've realized that TWiki.TWikiVariables uses the term "predefined variable". So I'm switching back the topic name.

-- Hideyo Imazu - 2013-08-29

While implementing and mentioning it on TWiki.TWikiVariables, I realized that $TWiki::cfg{OverridablePredefinedVariables} having a string value is better than $TWiki::cfg{PredefinedVariablesOverrideAllowed} having a boolean or a hash reference.

-- Hideyo Imazu - 2013-12-03

Further consideration led me to think that using a preferences variable OVERRIDABLEPREDEFINEDVARIABLES rather than the configuration parameter $TWiki::cfg{OverridablePredefinedVariables} provides flexibility - each web can have different set of overridable predefined variables.

-- Hideyo Imazu - 2013-12-04

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2014-05-07 - HideyoImazu
 
  • 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.