Update: See Jason Wood’s suggestion in the comments section for making this technique more secure.
INTRODUCTION
Today I want to take a look at a certain Perform Script On Server (PSOS) behavior, and for those who find this behavior to be inconvenient, propose a work around.
Here’s the behavior, or misconception, actually: a server side script initiated via PSOS (apparently) cannot access files on the server unless the user already has those files open locally. But of course there may be circumstances where you’d like to be able to access files server side that the user does not have open client side, either because the user’s credentials do not allow access to those files, or because you’d rather not have to open the files client side merely to facilitate a PSOS call.
If we consult the online help entry for running scripts on server, the official word is that server-side scripts can access other FileMaker files only when…
…in other words, if you want PSOS to be able to access files, you need to either a) already have the files open client side, or b) throw caution to the wind, and configure the hosted files to auto-open with pre-entered credentials.
Hmmm… I think we can agree that from a security standpoint “b” is a non-starter, and the whole point of this article is to avoid “a”. Fortunately there is a “c” option not mentioned above which I’ll get to shortly, but first let’s demonstrate the issue.
DEMONSTRATING THE ISSUE
With only File #1 open client side, we want to run this script on the server in File #2. The script consists of a single step, Exit Script, which, ideally, will pass a list of open databases back to the calling script in File #1.
This script will be invoked from File #1 via PSOS like so…
…but, in this example, if File #2 isn’t open client side, then it isn’t available server side either.
A WORK AROUND
This time, rather than targeting File #2 directly, the script in File #1 is going to invoke a second, server-side script in File #1 via PSOS. Once again, File #2 is not open on the client computer.
The server side script…
- checks to make sure it’s running on FMS
- does a re-login with credentials that are valid in both File #1 and File #2 (the privileges associated with these credentials should be limited in scope for common-sense security reasons)
- calls the script in File #2 (via Perform Script, not PSOS)
- passes the result back to the original script in File #1
And this time, here’s what we see:
CLOSING THOUGHTS
I recommend granting full access privileges to both these scripts as a security precaution. Here’s why: scripts thus configured cannot be viewed (or edited or deleted) by a user with less-than-full-access privileges, regardless of that user’s script editing privileges.
(Thank you Charlie Bailey at Codence for pointing this out.)