ExecutePluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on ExecutePlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the ExecutePlugin bug database.

ExecutePlugin Feedback and Development

First version posted, enjoy!

Thanks Alba Power Quality Solutions for sponsoring this plugin!

-- Peter Thoeny - 2014-10-20

Idea for enhancement:

1. Add caching feature: Optionally cache output for a certain time, useful if a report is slow. Can be done with a new cache="12h" parameter. Possible units are "1m" for minutes, "1h" for hours, and "1d" for days. A number without a unit character denotes hours.

-- Peter Thoeny - 2014-10-21

This is indeed a very powerful tool.

• With the script type, it can be used to create a GUI for system commands, including TWiki's own tools, and make them accessible to the web. This includes the tools used by TWiki developers in a SVN checkout. Yet another use case for TWiki as the glue to avoid media breaks (between shell and browser, in this case)!
• With the perl type, it can be used as sort-of a lightweight tag-defining plugin mechanism, with full access to the TWiki::Func API.

But with the power comes responsibility.

• In addition to the filtering, the scripts themselves should be thoroughly reviewed for undesired effects. They will run under the web server's user id. It is not guaranteed that the web server user has access rights to do anything useful outside the scope of TWiki, but it is guaranteed that she has full access to the TWiki data and pub directories, plus read/write access to LocalSite.cfg, the latter usually restricted to TWiki admins.
• In addition, the perl type has access to all the TWiki objects itself, not only the TWiki::Func API, but also the configuration and all the guts. Especially in a persistent interpreter, any effects of the script will start at unpredictable times (whenever someone views the topic), affect an unknown number of subsequent requests, and then end at unpredictable times (whenever the persistent runtime starts a new process).

Which brings me to another idea for enhancement:

2. Add access control: Everybody can save a TWiki topic with an EXECUTE{} element, thereby putting a land mine on the ground which is as powerful as the command permitted by the admin. The admin who permits a script for execution in configure has no control whether a topic containing EXECUTE{} is under access control, and who and when will view the topic. So I suggest he should get some control whether any viewer should actually trigger the mine.

• Of course, the admin himself will trigger any EXECUTE{} mine: If some TWikiGuest has added a suspicious topic and the admin just wants to see what it is about, he needs to be aware of ka-boom - underpinning the best practice to only use accounts in the admin group if really required for a task, and do day-to-day work like checking the wiki for abuse with a non-privileged account.

-- Harald Jörg - 2016-01-09

Good points, thanks Harald. I tried to make it clear in the docs how important it is to sanitize the call of the scripts. Please feel free to enhance the docs with your input.

As for access control, this would be a useful enhancement. As an idea, we could add a new topics key to the configure object. If set, the command can only be executed in the indicated Web.Topics (as a comma-space list). That way an admin can add a mine field prone script and lock down the topic that contains that EXECUTE variable.

-- Peter Thoeny - 2016-01-09