Jump to content

Keep Users from being able to execute scripts from Applescript?


Tyra

This topic is 3016 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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? 

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

This topic is 3016 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.