FILEMAKER 10: The FileMaker 10 Status Bar Buttons And Access Settings

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 4: More About Privileges

What happens to status bar buttons, like delete record, if the user does not have access to delete records. Is it grayed out, does it just not work, is there a notification?

I had to manually give this a try because I rarely use the FileMaker 10 status bar and even more rarely work with a database in a mode other than full access. What I found out is that the buttons are grayed out and un-clickable.

Here you can see the status bar while the user is signed in with full access. (click image to expand viewing area)

Here you can see the status bar while the user is signed in with read only access. (click image to expand viewing area)

Even more weird, you can customize the status bar in Read Only access. The icons become full viewable (not gray) and you can add icons to the status bar that you don’t have access to engage. Once you save your toolbar settings, the buttons will gray out again.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.

FILEMAKER: Substantive Privileges Explored

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 5: Combination Plate Protection

I have to admit, the first time I heard the term of Substantive Privileges, I was a bit bewildered as to its meaning. Looking at the dictionary meaning for substantive, one of the things we get is .... not imaginary; actual; real. So when is a privilege set a FileMaker user been assigned not the real one?

When a FileMaker user is running a script that has the “Run Script with Full Access Privileges” turned on, their substantive (or real) privilege set access restrictions are suspended during the execution of the script.

Now there is a wicked back swing in the use of this setting that can really confuse you. One popular Get function is the Get(PrivilegeSetName). The Get(PrivilegeSetName) function will return the name of the privilege set in use by the current database user.

If you run a script with the "full access" check box selected, it will always return the full access privilege set (and it's associated extended privs) during the scripts execution. So any script that branches in a different direction based upon the Get(PrivilegeSetName) returned result is useless in this situation.

It would be so cool if you could turn "run with full access" on / off during the script like you can with the Set Error Capture? Well, that isn’t an option for us thus far.

So if you want to know what the users privilege set actually is, within a script that is running full access, you would have to set a global field or global variable previously, within a script that is NOT running under full access. This would be akin to a stamping routine with privilege set information to a global marker instead of a dynamic calculation. Personally, I tend to put a Set Variable script step in my opening scripts that sets a global variable to the users sign in account name and their privilege set. It is just something I do by default, whether I know I’m going to use it or not.

Then you can query that global field / variable from there, instead of Get(PrivilegeSetName ), and it should return the correct result. Of course, you would have to re-stamp your globals if you have a re-login routine somewhere.

Another more obscure example of a Substantive Privilege can be when the Re-Login script step action is in play. In cases like this, you may temporarily assign a different user account and associated privilege set to user. However, the use of this is normally regulated to database testing, as a user wants to quickly test the security behaviors of an account without having to close the database and reopen it again.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.

FAQ: Protecting Credit Card Data Information

QUESTION: What is the most straight forward to remove access within InBizness for a majority of the users to clients credit card data?

ANSWER: The most straight forward way is to remove the field access permissions to the credit card related fields in the Clients module. This is done for each privilege set that corresponds to the business role of a staff member.

First up, open up the privilege set dialog box for one of the privilege set.

Under the records data access settings, choose the Custom Privileges option.

Next we want to choose the "limited" option for field access for the CLIENT table. This will allow us to target options for fields in the Client module.

From here, we want to remove the access for the privilege set for the credit card field. In the case of InBizness, these fields are have a prefix of cc_ .

So when you are done, it should look something like this.

The Field Access Setting Explored

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 4: More About Privileges

The Field Access Setting is part of the Record custom record privilege dialog box setting. Most of the FileMaker security settings are applied to the file, the table, the layout or the record. The field access setting allows you to apply a security setting all the way down to a particular field. Field Access settings will take precedence over the higher level settings that grant access. So a user can have access to a file, a table and a layout but you can set it up that they cannot view or modify data within a particular field. Now if the user does not have access to a file, a table or a layout, the field access setting under those conditions isn’t relevant.

Here you can see the custom record privileges dialog box and the setting for field access, currently this is set at none.

Here you can see the custom record privileges dialog box and the setting for field access. Here you can see the options for the Field Access menu for all, limited or none.

Down another level, you can see that you can choose field access to all fields and none of the fields for a table. The other setting, the limited setting allows you even more power and flexibility.

Choosing the limited setting, brings up this dialog box for access to modify the data in the field, only see the data or no access at all.

FILEMAKER: Testing Vulnerability

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 6: Security And The Business

FileMaker does not have a feature that can test the vulnerability of a FileMaker solution. There are such tools available in network design that can scan for network holes or places that are vulnerable to attacks. It is a shame because the development of a robust FileMaker solution can be difficult. It is always possible you missed one thing out of so many steps that makes a productive system as secure as it could be.

So the only way to be sure that a solution is safe is to test, test and test it again. The idea is to see if you can get into areas or perform actions you shouldn’t be able to ... while accessing the system under a particular privilege set. Without testing the vulnerability of a FileMaker solution, can you be sure that it is secure?

Now, if you have a nice set of security documentation ( including a security policy ), you can test for security results much easier. The idea is to document that this role can do this but shouldn’t be able to do that.

For example, log in with a user role for the shipping department and see if you can change an invoice. Another typical example is to log in with a sales person’s password and see if you can change the cost of a product.

This kind of testing isn’t the most exciting element of FileMaker design but it an essential aspect of database security protection.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2009 - 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.