From Dwayne Wright PMP
Certified FileMaker Developer
You can do a number of things to protect a database system and it is a very good idea to implement some of them into your FileMaker solutions. On the flip side of this topic, there are a number of things that can be done to bypass security settings.
To try to be ahead of the curve, prepare your databases to track as much hidden information as possible including user name, current date / time of database events and what the users are doing within your solution. These tasks can be accomplished by using various scripts and calculations and can be a real database saver!
Before I forget, I also suggest running regular reports on this data so you can catch inconsistent data entry or record access patterns. Looking at the patterns in which data in accessed, entered, edited and deleted can be a great asset.
Remember that you don't want to sacrifice the ease of use of your database for one bad egg. I had a user once that was very good at taking shortcuts and using various ways to bypass how data was worked with in one of my solutions. Each roadblock I threw up, a few days later they would find a technique to go around it. Finally, I specifically recorded his database usage. This lead to multiple insights including that there were unique aspects of the business that no one else knew about. Although he was hurting the integrity of the database system ( to a degree), he was fulfilling business needs. When the smoke cleared, we had a better database system that did not require data entry work arounds to address unique situations.
Here are some specifics about what you can do inside of your FileMaker solutions to make it a tad bit more secure.
Track Activity Of Scripts - One thing you can do is write a script that sets a log field equal to itself and some other information about what a user is doing. You can then run this script as a subscript of your major scripts. This can give you a pattern of who is doing what, when and how often.
Fully Script The Database Interface - In some situations, it is a good idea to fully script the database interface for actions such as going from record to record, table to table, layout to layout, etc... By writing scripts for all of these, you have more control and can build logging actions.
AUDIT DATA ENTRY
A number of times, data entry habits can give you insight into how your database solution is used and how to protect it. There is a very nice custom function and auditing FileMaker example at Nightwing Enterprises called Superlog. It can be found in their 848 example file collections. Here is a link...
PLEASE NOTE: Think carefully about adding customized security settings via scripts or calculations ... when ... you can do the same thing by using Accounts and Privileges. Also be sure to test any scripted / calculated logging or security settings.
If you make a mistake, you can damage the productivity of the database and give FileMaker databases as a whole a bad name. Not kidding, I’ve been to meetings where FileMaker (pre FileMaker 7) was ripped to shreds by it's users. Cryptic navigation, loss of information and even crashes ... all because the FileMaker solution was poorly designed with unnecessary homemade security options.
More info about the author and FileMaker in general, contact me at email@example.com.
© 2007 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.