Keep Users from being able to execute scripts from Applescript?

[Tyra]

Is there an easy way to stop users from being able to execute scripts from outside of FM, by using applescript. I have the script menu disabled/not present via a custom menu, but the scripts and other menu commands can be activated via applescript. Is the only solution is to give each script a custom privilege? 

[Steven H. Blackwell]

Apple Events is only one of several external API that can trigger a script.  Additionally, external FileMaker pro files can trigger scripts.  All this is by design.

A script designated as <<No Access>> within a given Privilege Set will not respond to most external API calls.

 

This behavior is one of the principal reasons I have cautioned against so-called "Scripted Security" schemes.

 

Steven

 

[Josh Ormond]

Another option, for those scripts that you really need the user to be able to run, is to add a script parameter from the button or trigger that fires it. In the beginning of the script, test for the parameter. If it doesn't include the correct parameter, exit the script.

[Tyra]

Thanks, wish there was a No access from external sources checkbox.. Going back through and changing 200+ scripts that need a variable, so that they wont run via applescript is not something I am looking forward to. But, I guess I now know going forward.

[Josh Ormond]

It is one of things that FM looks at it as, if you want them to be able to execute the script, they can execute the script from anywhere.

I suppose there would be a lot of outcry if they had done it the other way, where we had to individually specify where you could fire the script from.

[Steven H. Blackwell]

In the Privilege Sets you can select multiple scripts at once to mark them as <<No Access>> for that Privilege Set.  Please understand however that will render them inaccessible from a number of other places, including in many instances through the User Interface.

 

Josh Ormond's recommendation is one possibility.  However, if using it, be sure to protect the value of the parameter so that it cannot be learned by an attacker.

Steven