[Article] Privilege Bit Conflict When Creating Records

[Ocean West]

[blurb]

[big]

[color:red]Privilege Bit Conflict When Creating and Editing Records:

An Examination and Recommended Resolution

[/big]

By:

Steven H. Blackwell

Management Counseling Services

and

HOnza Koudelka

24U Software

The FileMaker® Pro 7 and FileMaker® Pro 8 versions share the same security and privileges schema. This system, first introduced in FileMaker Pro 7 is fully and extensively described in the book FileMaker Security: The Book.[1] In this mini–white–paper the authors want to explore a specific security and Privilege Bit configuration that may yield unexpected results. We will also advise several ways to deal with that phenomenon.

The security schema in the modern versions of the FileMaker Pro products is very granular. It allows for a very fine level of control over user privileges on a table by table and layout by layout basis. One particular configuration deserves special note however. There are instances where developers may wish to give users the ability to create records but not to edit them. Such systems are frequently used when signing into either physical or virtual spaces.

The ability to create a record however has always—in FileMaker Pro—carried the concomitant ability to edit it as part of that creation process. So what we are actually trying to achieve in these instances is the ability to create the record, enter some data into it initially, but then to lock it from further entry and likely from deletion. One way to structure the Privilege Set to accomplish this is shown below in Figure 1.

Figure 1. Setting Privilege Bits.

[/blurb]

What happens here however is not at all obvious at first blush. Users are allowed to create new record; but despite the prohibition on editing these records, users can edit them until the current FileMaker Pro “session” ends. This usually happens when the user exits the application. It can also occur when the user logs out of the file—an important distinction. {By the way, this capability does not extend to the deletion Privilege Bit, except for the ability to revert creation of a new record until it is committed.}

But until the session ends, even if the individual record is committed and even if the user leaves the particular record, that user can still edit the newly created record. Clearly in many instances this would be contrary to business rules that should be enforced. In regulated environments it would be a potentially significant security lapse.

There are several ways to address this situation. The first way is to change the Edit bit from no to zero (0). This is somewhat counterintuitive. However, it works. As long as the user does not commit the record, it remains editable. However committing the record will lock it; then it cannot be edited. And clicking anywhere on the layout outside of any of the fields will commit the record, if “Save record changes automatically” is turned in on the layout setup This may or may not be the desired behavior. Figure 2 shows the Privilege Bit setting to accomplish this.

Figure 2. Set the record edit Privilege Bit to 0.

A second way to address this situation is to script the creation of the record and then when the user clicks a button to confirm the data are correctly entered, have the scripted process set a value in a flag field that controls record editability. This process has the advantage that the record is not accidentally locked against further editing if the user happens to click outside a field. You can use two scripts to do this as shown below.

NewRecord

Allow User Abort [ Off ]

Set Error Capture [ On ]

If [ CreateEdit::lock=1 ]

  Exit Script [ ]

End If

New Record/Request

Loop

  Pause/Resume Script [ Indefinitely ]

  Perform Script [ Confirm ]

End Loop

Confirm

Allow User Abort [ Off ]

Set Error Capture [ On ]

Commit Records/Requests

[ No dialog ]

If [ Get ( LastError ) ]

  Exit Script

End If

Show Custom Dialog [ Title: "Confirm Data Entry"; Message: "Please Confirm these data are correct. After doing so you will no

longer be able to edit the record."; Buttons: “Cancel”, “Confirm” ]

If [ Get ( LastMessageChoice ) = 1 ]

  Exit Script [ ]

End If

Set Field [ CreateEdit::lock; 0 ]

Commit Records/Requests

[ Skip data entry validation; No dialog ]

Halt Script

In the Privilege Set definition disable the ability to create records via menus. Set the NewRecord script to run from a button that pauses the current script. You can either set the Confirm script to run from a button that pauses the Current script, or just have a button resume the Current script. Hitting Enter will also trigger the Confirm script. Note lines 3 through 5 of NewRecord These lines prevent creation of a new record via the NewRecord script while the current record remains in an unconfirmed state. If a user cancels the confirmation process, the pause continues in the NewRecord script.

The Confirm script first tries to commit the record, leaving space for any field validations. Then it sets a value of 0 into a field called lock. It is a number field, set to auto–enter 1 on creation. Once set to 0, the record cannot be edited if the Privilege Bit is set as shown in Figure 3. This is the standard Record Level Access process.

Alternatively to creating new records via a button, you can also use the FileMaker Pro 8 custom menus function to replace the standard New Record item with a call to the NewRecord script. But keep in mind that custom menus make your solution not only more convenient, but also more vulnerable, and using them makes you responsible for making them secure. Remember, that if you allow users the ability to create or to edit layout or to create or edit scripts that the user can override your Custom Menus with the default FileMaker Pro menu set.

Note that there are still some unhandled situations left, which you may want to address depending on your solution details. For example, any script that has a Halt Script step executed will stop the pause in the NewRecord script. Running the script in the Find mode is another example.

Figure 3. Set the lock field to 0 to block editing the record.

There is yet a third iteration for this process that developers can use. In this method, leave the Create Privilege Bit set to No as shown in Figure 4 (its default setting) and use the Lock flag process described above. Then set the NewRecord script to Run script with full access privileges. This assures that the script is the only way to create the record.

Figure 4. Leave the Create Bit set to No.

If using this construct in a variant of the Separation Model, remember that the script creating the record must reside in the data file and then be called from the UI file.

The authors have identified a potential unexpected behavior in Privilege Bits where developers desire to give users the ability to create new records but also constrain users’ ability to edit those records during a current session. They have offered three suggestions for managing privileges when business rules dictate this particular set of operational considerations.

About the Authors

Steven H. Blackwell is renown for his expertise in the areas of FileMaker Pro Security and FileMaker Server management. He has been working in the product since before it was acquired by Claris Corporation.

HOnza Koudelka has been developing FileMaker solutions since the time of FileMaker Pro 1.0. He co-founded 24U Software and started developing plug-ins for functionality missing in FileMaker Pro.

CreateEditRecords.pdf

[xochi]

Great article!

Question -- how does this work under IWP? I'd like to have an IWP layout to implement a "typical" web form, i.e.

1. create a new blank record and enter data.

2. have the record checked for errors via script.

3. edit the record if any errors are found.

3. commit the record, at which point nobody can edit or even view the record (for security purposes).

Does the rule "record is editable until the session end" mean, under IWP, that the record is viewable and editable until the IWP session ends or times out?

Edited April 4, 2006 by Guest
edited for clarity

[Steven H. Blackwell]

Does the rule "record is editable until the session end" mean, under IWP, that the record is viewable and editable until the IWP session ends or times out?

I sort of doubt this can be done in the way you describe, but it may be possible. Remember that there is no new record in the database until the information created in the browser is committed. Then perhaps a script can run to check validity. If there are invalid items, then a error would take you to an error page (no modal dialogs).

If all is correct then record is committed again and a flag set for RLA, blocking further access. But web user must be notified of action.

Let us know if you decide to implement this system.

Steven

[xochi]

I sort of doubt this can be done in the way you describe, but it may be possible. Remember that there is no new record in the database until the information created in the browser is committed. Then perhaps a script can run to check validity. If there are invalid items, then a error would take you to an error page (no modal dialogs).

If all is correct then record is committed again and a flag set for RLA, blocking further access. But web user must be notified of action.

Let us know if you decide to implement this system.

Steven

I've created such a system, and it's working fairly well. For details: http://fmforums.com/forum/showtopic.php?fid/51/tid/176901

[Stuart Taylor]

Would it be a daft suggestion to do the following

Test user priviliges if view+edit

Go to a creation layout with global fields.

gName_First

gName_Last

gEtc...

Save button

Script: Creates record that sets global data to record with full access running then clears global fields and returns to a read only standard layout.

Record remains read only thoughout.

?

Edited November 8, 2006 by Guest