Over the years I have noticed that some beginner and intermediate level developers are not aware of the possible uses of extended privileges, other than as a means of controlling methods of sharing (such as through standard FileMaker Pro to Server networking, Instant Web Publishing, PHP, etc…). Extended privileges are probably one of the most underused features in FileMaker and at the same time incredibly simple and powerful with regards to enforcing security and access control. I have seen people write very complex scripts that attempt to manage or limit access to specific areas of a system, creating elaborate, complex security access levels or hard coding some of this security functionality within the data structure when they could have used custom extended privileges to do the same in a cleaner and most efficient manner.
What are extended privileges? Extended privileges are just permissions that can be attached to an existing access privilege set and are used to determine whether a user has access to certain elements within a system or not. The most common type of extended access privileges are used to determine if users can access files via FileMaker networking ([fmapp]), ODCJ/JDBC, or the web publishing options.
Why are they powerful? FileMaker allows developers with the ability to create custom extended privileges, which are basically keywords, that can be called from any script, calculation or custom function in your file. This simple feature gives you the ability to setup access control groups.
Let’s say we are managing a system for a company that has three departments: Accounting, Production, and Sales. Each department has three levels of user privileges that need to be setup: a Manager level, a Supervisor level and a User level access. That’s a total of nine different privilege sets, not including development accounts.
We have a set of financial reports that must be accessible to all managers and to the accounting supervisors. For simplicity purposes, let’s pretend we have a script that runs all reports and at the beginning of this script we run a test to determine if the user running the script has access to these report; if not, the script should stop.
Without the use of extended privileges we could just setup the following script steps:
# test access
Set Variable [ $privilege ; Value: Get ( AccountPrivilegeSetName ) ]
If [ $privilege ≠ "Accounting-Manager" and $privilege ≠ "Accounting-Supervisor" and $privilege ≠ "Production-Manager" and $privilege ≠ "Sales-Manager" ]
# User doesn't have access
Exit Script
End If
# User has access, continue with reports…
A problem here could be if at one point in the future the developer decides to change the names of the access privileges, add more levels or departments or maybe revoke access to these reports to a certain group. He would have go into all the scripts that handle this restriction and make the changes.
The solution: we can create an extended privilege set called FinancialReports and assign it to the privilege sets that should have access to the reports. Defining a new extended privilege is as simple as specifying a keyword, giving it some sort of description, and then checking off which privilege sets should have it.
When it comes time to test for user access we can simplify our script steps with the following:
# test access
Set Variable [ $privilege ; Value: Get ( AccountExtendedPrivileges ) ]
If [ IsEmpty ( FilterValues ( $privilege ; "FinancialReports" ) ) ]
# User doesn't have access
Exit Script
End If
# User has access, continue with reports…
The Get ( AccountExtendedPrivileges ) function returns a carriage return separated list of all the extended privileges associated with the privilege set the account is part of. In this case, if we were logged in as an accounting supervisor, it would return
[fmapp]
FinancialReports
The FilterValues function compares that list to the second input (“FinancialReports”), and shows all matching values. So, if the result of the FilterValues function is empty with no matches, the user does not have access to the reports, and the script aborts itself.
This way, if we rename, add, or remove privilege sets or revoke or grant access to certain groups, our test won’t have to change (unless we rename the extended privilege itself, so it will require some careful planning on your part). In this scenario we can control access to these reports using only the custom extended privileges we created.
The same solution could be applied to other scenarios were there we have access to areas of a system that overlap within different accounts. For example, you might want to show a Daily Production Report to users in either the Production-Manager, Production-Supervisor, or Sales-Manager privilege sets every time they log in into the system.
