Feature Proposal: INCLUDEd Set variables should work

Motivation

Many people ask, over and over again, how to INCLUDE variable which are Set in another topic. The Workaround given is to use Spreadsheet Plugin. This violates both the Principle of Least Astonishment and the Rule of DRY (Don't Repeat Yourself).

I don't see this as a "security" issue. This is TWiki. If you can INCLUDE the page you can get t the code and if you can get to the code, al bets are off anyway as far as security goes.

Handle Access control separately if it worries you but don't disregard the need for answering the primary underlying problem by claimng "Security!"

http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item454

Description and Documentation

If I

* Set FOO 15

in topic CommonIncludes, then %INCLUDE{"CommonIncludes"}% into any other page, %FOO% should evaluate to 15.

Or, as one of my users just sad to me:

As an example, say, I'd like to be able to access the LAUNCH_ID variable in this document

   .../view/MyWeb/Src1181

And be able to use it in the child documents as well

   .../view/MyWeb/SRC_1181_PushToProd
   .../view/MyWeb/SRC_1181_PushToTraining

This is a frequently requested feature (and anyone with a programming background has a reasonable expectation that it should work!)

See

• EvaluateVariableSetInAnotherTopic
• IncludeFailsForPrefs
• FileOfWebVariables
• IncludedVariablesNotSet

TWiki:Main/VickiBrown

Hasn't this security issue been discussed over and over again?

-- TWiki:Main.FranzJosefGigler - 05 Sep 2007

Yep. However there is an argument that the %VAR variable should be able to look into other topics, and not just webs. or you might consider adding an option to %INCLUDE to import Set statements, filtering those that relate to access control, though I am not particularly keen on the idea.

Examples

Impact

Implementation

-- Contributors: VickiBrown - 07 May 2008

Discussion

Actually I prefer to think of %INCLUDE{}% as calling another context, that is, newly created variable in the new context are only valid there and are "disallocated" when the include finished. Using CALC isn't that far off. Another idea would be to store LAUNCH_ID in a formfield. That's probably the safest way to store and access "variables".

Other approaches are:

1. store variables in a table and use RenderTableDataPlugin
2. or FilterPlugin to extact it
3. or (miss-)use SEARCH to extract data from another topic.
4. or make it a proper topic preference variable and get it using DBCachePlugin
5. yet another way to temporarily set variables is to use a parametrized INCLUDE. The variable will be set in the called context. Though this is just the opposite of what you wanted first. Anyway, maybe your app can be designed to make use of this mechanism in some way to avoid this all.

-- MichaelDaum - 07 May 2008

It wasn't just a security issue, it is an issue which will break some of today's TWiki usage unless it is implemented as an additional parameter which defaults to "leave it as it is". See IncludeShouldIncludeSettings, where concerns have been raised by CrawfordCurrie, ThomasWeigert, and myself. I still think that an agreeable spec could be written, only that nobody took the effort back then.

-- HaraldJoerg - 07 May 2008

The problem with using CALC or RenderTableDataPlugin (or any other plugin) is that the ability to include a variab;e (something any programmer has a right to expect) should be easy to do. It shouldn't require installing something else or changing the way the included page is set up.

An additional parameter to INCLUDE is fine. Perha[s an "execvars" param.

I still think that an agreeable spec could be written, only that nobody took the effort back then.

-- VickiBrown - 28 Jul 2008

I'm more inclined to use a new var, instead of overloading INCLUDE. It could be, as Harald mentioned somewhere else, PROCESS. Be it a new var (PROCESS) or a new setting of INCLUDE ("exportsettings=on") the spec could be:

• It will behave exactly as INCLUDE behaves today regarding sectional includes and passed variables.
• Any and all settings (both those using the SET syntax and the META:PREFERENCES one) will be included in the context of the including topic, except for those used for ACL.
• Settings will be "rendered" before the topic is being included, so they cannot use any setting defined in the the including topic.

how is that for a start?

-- RafaelAlvarez - 28 Jul 2008