The problem with the fmp-url protocoll is that the script-calling functionality is fused together
with the ability to define variables (above all $$variables).
Whereas the ability to call filemaker scripts via url is an extremely useful and - at least since the introduction of the OnExternalCommandReceived Layout Script Trigger - a relatively secure functionality in FileMaker.
The possibility to define ($$-) variables, however, represents a security hole, since users are thus able to set, create or change potentially critical $$-variables within a file.
As David Wikström noted in the DataViewer allows access to blocked content discussion:
fmp urls are another great way of declaring variables with just a browser, no advanced or funny tricks required. You can of course block fmp urls entirely for a file, but that’s sometimes a steep price to pay.
The problem is that the price of turning off fmp-urls is TOO steep for some developers, who then open up a security hole in their solutions in order to use the comfort of the fmp-url protocol.
We need a finer control of fmp-url permissions, so that we can disallow variable-definition via fmp-url whilst still allowing script-calls by fmp-url. Like that we can utilize fmp-urls for script calls - for web viewer call-back, etc. - without breaking the security of $$variables.
- Variable definition via fmp-url should be disallowed by default
- A new extended privilege 'fmextvariabledefinition' (or similar) should be introduced to allow definition of variables via fmp-url (for those that really want it / nedd it)
In my opinion defining $-variables represents just as great a security risk as defining $$-variables (*), and that we should thus treat $-variables the same as $$-variables, and thus require only one new extended to privilege to turn ALL variable definition on and off.
Maybe other developers use the fmp-url to set $-variables, I personally do not, and feel data can and should be safely passed to a script via script parameter.
(*) It is - sadly - relatively common practice amongst FileMaker Developers to NOT initialise all variables - the logic of the script assumes all used variables have an initial undefined value of null (i.e. ""). This makes it possible for a user to call a script and cause unexpected results by initialising local variables to non-null values. For example, it is possible in an fmp-url-call to define a looping-variable, $i=5, in order to skip the first elements of a loop.
- Higher Security
- ($$-)Variables are secured
- Security is not comprimised by developers turning on fmp-url for script calls
- Better leverage of existing powerful technologies:
- fmp-urls can at last be used safely to call scripts from other applications
- web-viewers can use fmp-urls for call-backs, making interactive web-viewers easier to programme securely
- Improved Integration
- FileMaker is easier than ever to use.
- Creating a secure filemaker app
- iOS Apps
- Calling scripts from external applications
- Interactive web-viewers
Idea 2 - FILE-level script trigger "OnExternalCommandReceived"
And of course, the icing on the cake of this idea would be a FILE-level script trigger "OnExternalCommandReceived", so that external script calls can be centrally handled within a file - instead of the developer having to add the script trigger to EVERY layout (which is easily forgotten when adding new layouts). Like that you can filter or entirely block callable scripts easily & in one place.
Happy + Secure FileMaking!