Execution of arbitary scripts

A small, but quite handy new facility in MidCOM does now allow for the controlled execution of simple scripts from within MidCOM, without having to explicitly build pages or the like to launch them in a Midgard environment.

Script execution is limited to the exec subdirectories of all components and to the midcom/exec directory. Main target of this facility is the simple execution of small scripts in full MidCOM context, for example for data upgrading (which is its actual first use as a matter of fact.)

Documentation excerpt

Allows you to execute certain php files directly, in full MidCOM context. The argument is the name of the component, which holds the script to be executed. Script files are searched in the subdirectory "exec" of the component. If you use "midcom" as component name, MidCOM core scripts, located in lib/midcom/exec will be accessible. The next argument on the command line must be the name of the script file. Accessing subdirectories is not possible, only a single argument will be taken.

The scripts executed need to do their own permission checks, they will work with the credencials of the current MidCOM instance unconditionally.

Example: http://$host/midcom-exec-midcom/upgrade_metadata.php

Taken from: CVS documentation of midcom_application

Usage considerations

The programmers side

Exec scripts should always be written in a way so that they do not modifiy any data unless a user somehow confirms the scripts execution. Your script can usually rely on external authentication, so you should be able to directly get down to the permission checks without further code.

A good way to block invasive scripts like content updaters is adding a die call at their start stating that the user should remove this "die" to allow for script execution. Of course, this does block automation. An alternative might be having a simple "OK" form displayed.

Besides from this recommendation, all scripts do run uncached automatically, and MidCOM execution is terminated after the script file ends.

For this reason, calling exit within the script is not recommended, instead, call return which will return execution back to MidCOM which will then clean up after the script. Alternativly, you can call midcom_application::generate_error() under any error condition as usual.

If you need any configurability, use variables within the script for an easy solution. Just keep in mind, that you are working within a function's scope, not on the global scope. So your config variables must either be declared as global explicitly, or passed to your functions manually.

Usage of MidCOM subsystems should be like usual, though I have not yet tested this. Especially dynamic_load could cause problems here. Also, it is not possible to dynamic_load exec pages, as they exit after processing.

These script files have to be documented using PHPDoc like usual, indicating how to launch them. Functions you require inside the script should not be documented with PHPDoc, as these functions are not callable from the outside anyway, and would therefore just clutter up the API reference.

The users side

Any upgrade scripts delivered with MidCOM using the exec interface will be disabled for now using a die call by default. You should keep this protection in place, just in case anybody stumbles acidentially (or maliciously) on these pages.

The first upgrade script I wrote does require admin privileges, so the security risk is minimal, but I find it better to live on the safe side. It is important that you check the upgrader scripts before execution, as most of them will contain some configuration options at their beginning.

Of course, the non-volatile scripts in use, that might be used with HTMLArea & Co. are checked against security so you should be able to leave them active at any time.