Going through the code and trying to understand exactly how interactive and non-interactive activites get "triggered", I found out - well, actually confirmed what's is written in the documentation - that Galaxia uses the 'fopen' function using the Galaxia 'tiki-g-run-activity.php' URL (all of this being defined in the 'galaxia_execute_activity' function, in the 'lib/Galaxia/config.php' file) to "trigger" the execution of non-interactive activities.
This behavior requires the PHP 'allow_url-fopen' setting to be enabled (see http://ch2.php.net/manual/en/ref.filesystem.php#ini.allow-url-fopen ).
By those cross-scripting and website defacing days (I personally know of two companies who went into major problems because of that, one being a government administration who involuntarly got involved into phishing attempts...), basing a software on the requirement that 'allow_url-fopen' is enabled is kind of a bet!
Google: allow_url_fopen security
My company policies are quite strict on this issue: NO WAY (repeat: NO WAY !!!) 'allow_url-fopen' shall be enabled.
MY requirements being put apart, are you 100% confident that Tikiwiki is invulnerable to cross-scripting attacks ?
Now comes my prososal; I haven't implemented it yet, so I'm not sure it would work, but those who know the Galaxia Workflow Engine inside-out might actually immediately tell whether this proposal may work or not:
Currently, the 'galaxia_execute_activity' URL-fopens the 'tiki-g-run-activity.php';
Why not do it the other way around - have the 'tiki-g-run-activity.php' call the 'galaxia_execute_activity' function - and make sure the latter verifies _REQUEST data are present and, if not (in case of non-interactive calls) create its 'non-interactive' equivalent ?
No 'allow_url_fopen' would be necessary then...
Or am I missing something enterily ?
Thank you very much for your feedback !