Scripts and Security

Security and scriptwriting intersect in two areas. First, you need to take into account the level of access people have, and whether or not your scripts will over-ride some or all of their privileges. (The previous section describes one way of doing so with extended privileges.) Second, FileMaker lets you automate some of the security features described earlier in this chapter with scripting. ScriptMaker has a handful of steps dedicated to security-related tasks, and this section shows you how to use them.

16.5.1. Detecting Privileges in a Script

The first way to handle security in your scripts is to deal with it directly. In the last section you learned how to check for extended privileges and take appropriate actions. If you want, you can check for specific privilege sets, or even specific account names.

• To check the privilege set, use the Get ( PrivilegeSetName ) function. It returns the name of the privilege set assigned to the current user. Bear in mind that if you change the name of a privilege set, you have to modify any scripts that use this function.
• If you must restrict an action to a particular account, use Get ( AccountName ) instead. As you probably expect, it returns the name of the account with which the user logged in. The same warning applies here: Beware of renamed accounts.
• Finally, FileMaker has one more tempting function: Get ( UserName ). This function normally returns the user name from the computer's operating system (the name you use to log in to the computer itself). If you use shared accounts in FileMaker, you might want to use the user name to find out who's actually doing something.

These functions are easy to use, but they have some drawbacks. Chances are you'll need to change the account names, privilege sets, or users that can do certain things at some point in the future. Every time you do, you have to check and probably edit all your scripts.

Furthermore, the Get ( UserName ) function has a severe limitation: Anybody can change it at any time. In FileMaker's preferences window, under the General tab, FileMaker lets anyone type in any name they want. This characteristic means it's easy for someone to pretend to be someone else. For this reason, you should never rely on the user name for security purposes. If you want to secure a scripted process, the extended privilege feature described on Section 16.4.3 is safer and makes it much easier to update accounts and privilege sets.

16.5.2. Handling Security Errors

If your script tries to do something that the user isn't allowed to do, FileMaker shows the error message in Figure 16-18. If you turn error capture on in your script, this error doesn't show on the screen. Instead, you can use the Get ( Last-Error ) function to check for an error (Section 15.4). That way, you can have the script display a custom message box, or email you the name of the misbehaving person, or take some other action. The most common security-related error is number 200: Record Access is Denied. (If you're interested in learning more about error codes, check out the resources in Appendix B.)

Figure 16-18. When someone tries something your security setup doesn't allow, he sees this messageeven if it's a script that's breaking the rules. Unfortunately, FileMaker doesn't tell himor youwhat it's trying to do.

 

16.5.3. Running Scripts with Full Access Privileges

Sometimes you want the script to do its duty even though the user doesn't have the necessary privileges. For example, you may want to remove an accountant's ability to delete Invoice records since she's not supposed to delete any orders. But you may still want to let her run a script that finds old completed invoices, exports them to an archive, and then deletes them. Since this script is careful to delete only invoices that are ready to go, the accountants can safely run it when necessary.

For those kinds of circumstances, FileMaker lets you specify when a script should run with full access privileges for anyone. In other words, the script overrides the normal restrictions you set up in the user's privilege set. At the bottom of the Edit Script dialog box, just turn on the "Run script with full access privileges" option (Section 13.1.3). With this option turned on, the script dutifully deletes the invoices even though the accountant running it isn't allowed to delete records in the Invoice or Line Item tables herself.

Even when you set a script to run with full access privileges in this way, you can still prevent some folks from running it by switching it to "no access" in the Custom Script Privileges window for a privilege set (Section 16.2.3.6). You can also make the script check for an extended privilege and take appropriate actions for different people.

16.5.4. Managing Security with Scripts

ScriptMaker's Edit Script window (Figure 13-2) has an entire section called Accounts. It includes six steps that give you some control over the security system from your scripts. All of these steps require full access privileges to work. If you don't manage a lot of accounts in your database, you might not find much use for these steps. But if you have a large organization, or one that has lots of turnoverlike a school system that's constantly adding new teachers or graduating a whole class of students who no longer need access to databases for class workthese script steps can save tons of time and effort.

16.5.4.1. Add Account

FileMaker actually lets you add new accounts to a database from a scriptand for good reason. If you build a system that uses several databases, and you can't use external authentication, the Add Account step is your best friend. Instead of adding each account to all your files manually, try this: Write a script that asks for the account name and password with a custom dialog box, and stores them in global fields. Then use scripts in each file to add the same account to every file at once. When you're all done, be sure to clear the password from the global field to protect it from prying eyes.

Or, if you have to populate your brand-new file with a huge number of users when you're first installing your database, you save tons of time creating accounts if you have an electronic list of user names and passwords. Import them (Section 17.3) into a table, and then use a looping script to create hundreds of accounts in a few seconds. The Add Account step lets you specify the account name and password using calculations, but you have to select a specific privilege set for all users in the loop. If you want to script the creation of accounts with different privilege sets, use the If/Else If steps and several copies of the Add Account step.

16.5.4.2. Delete Account

If you're going to create accounts with a script, why not delete them too? The Delete Account script needs only an account nameand you can supply it with a calculation. With this script, you can build the other half of your multi-file account management system.

---

Warning: If you write a script that adds or deletes accounts, pay special attention to its security settings. It's all too easy to give a database the tightest security FileMaker allows, then leave a gaping security hole through a script. Customize privilege sets so that only you (or a trusted few) can run it, and don't put it on the Scripts menu.

---

16.5.4.3. Reset Account Password

If lots of people use your database, forgotten passwords will undoubtedly become your worst nightmare. You could spend all day changing passwords for people. Why not write a script that can reset a password to something generic and then email it to the user? If you set the script to run with full access privileges, you can even delegate password resetting to someone else. The Reset Account Password step needs an account name and a new password to do its job.

16.5.4.4. Change Password

This odd step doesn't see the light of day very often. After all, folks can change their own passwords with the File Change Password command (it only shows in accounts that dont have full access). You could use this step to create a Change Password button if you have users who aren't very good at remembering where menu commands are either.

16.5.4.5. Enable Account

Once you've created a bunch of new accounts using the Add Account step, this step lets you turn them on and off at will. That way, you can create accounts for, say, an entire class of students, and later turn on accounts for those who've arrived on campus. This step does the same thing as make active and make inactive) in the Edit Accounts dialog box, and it works only when there's a valid account name.

16.5.4.6. Re-Login

The most exciting step in the Accounts section is Re-Login. It provides a function that doesn't exist anywhere else in FileMaker. Namely, it lets you switch to a different account without closing the file, which gives you almost superhuman ability to test security settings. Instead of opening and closing the files until your mouse button wears out, just run a Re-Login script. Add steps in the script that set global fields on pertinent layouts to Get (AccountName) and Get (PrivilegeSet) so you can keep track of what you're testing as you Re-Login over and over.

You can also use Re-Login when someone inevitably calls you to his desk to show you a problem in the database. Just re-login as an account with full access and then you can poke around and find out what's happening on his computer. When you re-login, you're not just saving time not closing and reopening the file. You can actually work in the same window, on the same record, with the same found set and sort order without all the trouble of recreating the situation back at your desk. Again, since you can re-login only from a script, consider adding a Re-Login script to the Scripts menu in every database you create.