A READER ASKS: Limiting exposure

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

APPENDIX 1: A Reader Asks

A READER ASKS
If your too busy to help I understand. I’ve set up user account privileges with no problem. The Field “Created By” is auto filled with (AccountName)

The problem is, I want the user to be able to enter data and flip through the records without seeing that , for the records that he doesn't have permission to view. I assumed that best way to do this is to create a “Go To Record” script that would go to the next record (or previous record) with the value of current (AccountName) in my field “Created By”.

Does this make sense?

I know this can’t be hard but I’m kind of new to this.

The step I’m using

1 create button
2 Go To Record/Request/Page
3 Specify: By Calculation
then I have no clue.

Sorry, recent picture of my dog at a camping site we visited in California. Couldn't help myself! (grin)
-------
DWAYNE RESPONDS
You are on the right track and just about there! You will need to create a script for your record navigation. Simply passing over records the user does not have access to see, is one way to go. It may confuse a user in situations where they see a found set of records of 10 (for example) but they can only view 2 of them. Another way to go is to add a constrain found set command to your searches and reports. This could be used to move restricted access records to the omitted set. So you will want to investigate options of passing over records or simply removing them from the users browsed found set.

The more I think about it, I’m leaning more to the omit method. You can setup a scripted routine that automatically omits the records the user does not have access to view. After each search, you run a scripted routine for omit related actions. If some restricted view records make it through the system, omit them separately as the user navigates from one record to the next, change modes or navigate to different layouts. This method gives the user a more true representation of the records they can view and work with.

Although you can accomplish this coding with the last few versions of FileMaker, the script trigger feature of FileMaker 10 would be a very nice fit for you here. If you don’t use FileMaker 10, you are going to hide the status area and create your own record navigation buttons. If you are using FileMaker 10, you can use record, layout and mode triggers to continually tweak your found set.

WARNING: FileMaker 10 has made some changes in the way calculations are referenced and extended privilege sets are no longer supported in record level access controls. Refer to the FileMaker KnowledgeBase article 7161 for more information.

Here are some links to other posts that might be of interest in regards to this topic...
The Status Area - ( Hiding, Showing And Mimicking)
The Constrain Found Set Script Step
Constrain Found Set
EXAMPLE: Constrain Found Set
Controlling The Found Set Of Records
EXAMPLE: Constrain Sans The Find
Fast Match
EXAMPLE: Omit In A Multiple Request Search
Audio Comment About Episode 20 Of FileMaker Success Tips
Constrain Found Set
FileMaker 10 Saved Finds (Constrains And Extend Routines)
Multiple Criteria Searches
=
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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

A READER ASKS: Security And The Relationship Graph

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

CHAPTER 09: The Separation Model

A READER ASKS
We have multiple files in our FileMaker solution. We have instances where a user has full access in one file and does not have full user access in the second file. In regards to our mixed access users, looking at the relationship graph for the file they have full access to ... what does the relationship graph look like?

-------
DWAYNE RESPONDS
I have to admit that I don’t have a lot of solutions that use this type of configuration. I decided to try a “real world” test on this and my results seem to indicate ...

the user doesn’t seem to have any relationship graph restrictions in a mixed setting mentioned above. Check out the movie below and feel free to share any experiences you may have.


There is a related movie on this topic! CLICK HERE!

=
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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

FILEMAKER: FileMaker 10 Security, A Quick View (Part 1)

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

APPENDIX 3: Leftovers

I have covered the topic of FileMaker Security comprehensively in the FileMaker Security Explored blog. That isn’t to say that you shouldn’t continue to explore the topic at every opportunity and get as many viewpoints about this important area of FileMaker development as you can. I would never recommend that there is one place or one individual with complete knowledge of database security, particularly in this ever evolving technology age.

In this blog, we have covered security as a holistic concept, accounts & privileges, passwords, combination plate protection, business specific issues and even responded to some reader questions. I thought I’d take a moment to try and condense much of this information done into a set of highly condensed blog posts and then encourage you to investigate these topics in more detail. So this is the first in a set of quick fire comments about FileMaker security as I know it.

Base FileMaker protection is provided by a system of accounts and associating a defined privilege set to that account. Account settings include authentication type, account name, password, active/inactive, its assigned privilege set, comments and if the password needs to be changed on the next login. A privilege set (which is assigned to the account) is a bundle of selected security options and an account can be assigned to only one privilege set at a time. Default privilege sets include Read Only, Data Entry Only and Full Access. Knowing the particulars of setting up your own defined privilege sets for your workflow needs is one of the most important aspects of FileMaker security.

In most cases, FileMaker authenticates user credentials within the FileMaker file itself but external authentication options are available. In many published areas, FileMaker themselves declare that the best practice is to have a unique account created for each user of a database system when internal authentication is used. FileMaker does ship with some default accounts and it is recommended that you deactivate or rename these accounts as soon as possible because they are obviously no secret. This is particularly true if the FileMaker file is being hosted and is readily available to multiple users on a network.

A FileMaker file can be setup to have a default account and password activated when a file is opened. This means that any user opening the file will not be challenged for an account name or password. The file opens with the default account (and associated privileges) and can be used as a time saver in some situations. It can also be considered a potential security risk in other situations. Bypassing this setup can be accomplished by holding down specific keyboard keys as the file opens (Shift Key - Windows) (Option Key - Macintosh).

In regards to scripting, some basic security settings can be controlled via FileMaker scripting and these include

- account creation/deletion/active?
- reset/change password for an account
- re-login with alternate account

As a developer, you can assign an option to a script to behave like the user has full access privileges for the duration of the scripts execution. Using this setting, a script can still perform its intended purpose, even if the users security settings would normally forbid portions of it.
=
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.

==================
ADVERTISEMENT (Virtual One On One Training Services)
If you are interested in a one on one virtual session, please click here or send me an email at info@dwaynewright.com and we will schedule an appointment.

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.

Here are some links to other posts that might be of interest in regards to this topic...
Permanent Removal Of Design Features Explored
Get(PrivilegeSetName) Returns “Full Access”
EXAMPLE: Copy All Script Step Breakage
=
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.

=============
Unpaid advertisement for a something I recommend
I am a big fan of listening to daily shows on my iPod as downloaded from iTunes. These shows are called podcasts and a unique FileMaker specific one has come on to the scene I’d like to share with you. It is called FM Success Tips and it is a weekly 20 minutes dose of FileMaker that you can listen to in the car, at the gym, at the office or wherever! You can subscribe via iTunes or listen to it on the web at http://fmsuccesstips.libsyn.com/index.php?post_category=podcasts !

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.

FILEMAKER: Security Settings In The Separation Model

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

Security in a FileMaker database can always be a bit tricky and this is a bit more complicated for a separation model implementation. In the separation model, the user accounts (with the same passwords) will need to exist in each file. When the user logs into the user interface file (on the front end), they will also be logging with the same user name and password in the data file. If you don’t set it up this way, the user will be asked for their credentials when the data file tries to load. Just because they are the same account, that does not mean they have to be assigned to the same or similar privilege sets. In fact, that will rarely be the case.

So each file will need to have the same user name, the same password for that user name but not necessarily assigned to similar privilege sets.

The traditional way to manage accounts and privileges.

If you have a small set of users and a potentially small amount of necessary security related changes, you might want to do security edits by hand. Under other conditions, you will likely want to script the ability to change security settings. This means that some of your power users / administrators can make staff level security changes without going “under the hood” to the Manage Accounts & Privileges dialog box. This also means that you batch update security settings (which can happen in a fragile economy like ours and many users get laid off).

Although my FileMaker CRM framework product InBizness does not use the separation model, it does have some scripted security capabilities. You can view a movie on these by visiting http://www.dwaynewright.com/inbiz/movies/modules/staff.mov .

I also created an example file for this some time back. It can be downloaded at ...
http://www.dwaynewright.com/blogfiles/script_admin.zip

SECURITY ACCOUNT RELATED SCRIPT STEPS
There is an entire family of script steps called ... you guessed it ... the Account script steps. Using these script steps within ScriptMaker, you can help make the account management tasks much easier than a totally manual process. The scripts steps are listed below and the title pretty much describes the function!

Add Account, Delete Account, Reset Account Password, Change Password, Enable Account and Re-Login. By the way, the re-login script step can be great for testing your database. You can easily switch between different account settings and never leave a layout!

The Re-Login script step allows you to exit the application under one user account and immediately log back in using another security account. The actual file does not need to be closed in order to do this and makes testing of security accounts much easier on the FileMaker developer.

Now the account name and password can be hard coded, use the calculation engine (via the specify button) or left blank. When blank, the user will be prompted to enter in the blank value (the account name, the password or both). In situations in which the user needs to enter in the account name or password, they will get 5 tries to get it right. If the user cannot get it correct within 5 tries, the database closes completely

BACK TO THE SECURITY SETTINGS THEMSELVES
The security settings for data access, for the most part must be set in the data file(s). That makes sense, since that is where the data lives. However, the separation model is a balancing act between user interface (UI) and data. The security settings are not always cut and dried. This means you should plan out as much as you can before you get started and test it as much as you can when you are done.

Here are some links to other posts that might be of interest in regards to this topic...
Testing Your Security Settings
Why FileMaker Solutions Are Sometimes Not Secure
Database Design & Information Integrity
Testing Vulnerability
=
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.

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

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.

Here are some links to other posts that might be of interest in regards to this topic...
Privilege Sets & Working With Records
EXAMPLE: Record Level Access By Account Privilege

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html