Restricting Record Creation

[Wickerman]

Because I've mostly designed databases for my own use, my general development skills have gotten well ahead of my security savvy. I'm currently building my first database in which I want to tightly control record creation, deletion, etc. according to privilege sets, custom menus, etc.

Is there a white paper or other resource that covers a good range of basics and strategies for "locking down" a solution in terms of record creation, deletion, etc -- I don't need to read about privilege sets and accounts, I'm talking about how, for instance, to stop a privileged user from using the CMD-N keystroke command instead of a scripted button I'm creating to provide a new record with the needed keys, etc.

For instance, at DevCon, I picked up a technique of unchecking the "run script with full access privileges" box in concert with a test that checks for a user's privilege set before triggering a subscript that runs with full access *on* -- but I'm fuzzy on how to deny record creation in the first place.

Clearly a lot to learn - any pointers appreciated!

Albert

[Fenton]

Well, the setting you likely want is in Accounts & Privileges. It's the "Available menu commands", at the lower right. You want either "Editing only" or "Minimum." Those disable the command keys; including Find; so you need to put buttons for those. It would be nice if there were 4 options, one that allowed "non-data changing" commands, like Find to stay, but disabled all others. But there isn't, and I suppose it would be hard to decide which those were.

Another alternative, which lets you keep the command keys, would be a Custom Menu Set for each level of use (and possibly each table requiring different scripts for an action), where you would change all of the relevant menu commands to run a script of yours instead, and disable others you didn't want them to use (Find & Replace, etc.). That is pretty time intensive to develop.

[Steven H. Blackwell]

I'm fuzzy on how to deny record creation in the first place.

By using the privilege bit options in the Define Privilege Set area.

[color:red]And I might add this is the only reliable way to manage privileges to create a record. Manipulating the User Interface will not reliably manage the record creation privilege.

Download the Security Tech Brief on the FMI web site. You may reliably ignore the author's many eccentricities.

Steven

[Wickerman]

Thanks to you both -- I'm fiddling with the options today and making good progress, I think.

Steven -- I'd really like to read the document you mention,, but I'm having a hard time locating it on the Filemaker site, by either browsing or searching there. Might you be able to point me more particularly to this resource?

Thanks!

albert

[Steven H. Blackwell]

Try here.

Steven

[Wickerman]

Ah - thank you. I have a couple more fine-grained questions, if I may:

1) I've successfully scripted a record creation button that first checks the User's privilege set and if it = "Curator", calls a separate sub-script with Full Access Privileges checked that simply performs "New Record". Okay.

So, I was wondering whether I could simplify things by doing this with a single script (Full Access box checked) with an "If" statement that creates the record if the match is true and delivers a dialogue box if it isn't (see attached script picture). This doesn't seem to work, though -- why not?

2) I'm trying to think ahead about what sort of Privilege Set "test" is best to use. Instead of a perfect match with "Curator" should I maybe use a PatternCount test = >1 on some character string I might include in any number of privilege Set Names that I might later like to create that would enable the User record creation abilities via my scripts? It's these sorts of practical strategies I'm hoping to get in place from the get-go.

thanks again

Albert

[Fenton]

1) Get ( PrivilegeSetName ) = "[Full Access]" when you [x] Run with full access, so you can't check it in the same script. So you need 2 scripts to do this.

An alternative to putting "New Record" in a subscript is to do it the other way around. Have a single subscript that sets the Get ( PrivilegeSetName ) into a global variable. In all your other scripts that need to run with Full Access, call the same subscript to get the privileges. That way you only need the 1 extra script, for all scripts that need it.

I don't know for sure if that is as secure, but it would save having wrap all these scripts in another.

2) My general rule is "start checking from the top", which it seems you're doing. Never check for "lower" levels. Because, in my experience, you often add lower levels, more seldom add upper levels. If an upper level test fails (forgot to add it to the tests), then the worst that happens is someone can't do something, they tell you, and you fix it.

If you base tests on lower levels and you forget to add one, they can do things they are not supposed to do, and no one will notice.

If you need to know whether someone "is" a lower level, you do so with a "negative" test, ie., they are "not" one of the upper levels.

Another idea which helps if you have many levels is to use Extended Privileges. You can assign a single Ext. Priv. to several Priv. Sets, which makes it easier to check for that, using Get ( ExtendedPrivileges ).

Full_Access_wSubscript.fp7.zip

[Steven H. Blackwell]

First, note Fenton's excellent comments regarding what Privilege name is returned in a run script with full access privilege script.

You could pass the current user's Privilege set name to the script as a parameter from the button that calls it.

But the important question is this:

What are the settings in the Privilege Set for the "Curator" for creating records?

Steven

[Wickerman]

Thanks -- these are exactly the sorts of details / issues I'm looking to grasp, and the effect of [x] Full Access on the Get[PrivilegeSet] result sure explains things.

Currently, I have my Curator privileges being quite expansive, but for the purposes of restricting Record Creation/Deletion to my interface scripts, I've disallowed those privileges in the 'Curator' set. I'll also be disallowing Layout mode, I expect, but while devewloping I find it helpful to be able to slide into Layout when testing the design. Is that what you had in mind, Steven?

Albert

[Wickerman]

Hi Fenton -- am implementing your suggestion using the all-purpose "Get_Privs" scripting suggestion, but have added a twist I'm thinking will yield some flexibility: by employing an "If" statement in the subscript that passes either "Allow" or "Prevent" based on the results of the Get(PrivilegeSetName) parameter, I figure I can add further Privilege Sets to this single subscript if I want to accord the Record Creation ability to other sorts of users who enjoy as-yet uncreated Privilege Sets.

I'm feeling pretty good about this -- does it look appropriate to you guys? Any problem I'm not seeing?

Albert

[Fenton]

Actually I forgot to say, my latest method is to put the tests into a Custom Function. This has the advantage that if you do add a higher level Privilege Set later, you just have to add it in one place. It's also a lot shorter in the script. It is not as flexible however, if you want something special for a particular script. But you could have more than one CF, if it is a known group of privileges.

So this is an even shorter way to do it. I like better, as it doesn't use a global variable.

Full_Access_wSubscript.fp7.zip