4 Replies Latest reply on Dec 6, 2012 12:04 AM by DamonCasey

    Privileges in one file don't work correctly for layout in separate file

    DamonCasey

      Summary

      Privileges in one file don't work correctly for layout in separate file

      Product

      FileMaker Pro

      Version

      12.0v3

      Operating system version

      Mac OS X 10.7.5

      Description of the issue

      A privilege set in a file called DTData only allows editing of records in a table when a field in that table called EditRecord = 1.

      A script in a file called DTAdmin is performed from a layout based on DTData's table that performs a script in DTData set to run with full access privileges that toggles the EditRecord field between 1 and 0. The script in DTAdmin sets a global variable to Get ( RecordAccess ) and at the end of the script clears the global variable from memory.

      After performing the script, which set EditRecord to 1, the record isn't immediately editable in DTAdmin and requires the record to be committed in DTAdmin before the record becomes editable.

      I've built an example in FileMaker Pro 11 Advanced and the issue doesn't exist in 11, it only occurs in 12.

      Steps to reproduce the problem

      Perform a script in DTAdmin that performs a script (set to run with full access privileges) in DTData that sets EditRecord to 1 or 0, based on what the field's value already is (if it's already 1, it is set to 0).

      The DTAdmin script must set a global variable to Get ( RecordAccess ) and then clear the global variable after setting the EditRecord field.

      Try to edit the record in DTAdmin,

      Expected result

      If the script in DTData set EditRecord to 0, the record should not be editable. If the script set EditRecord to 1, the record should be editable.

      Actual result

      If EditRecord is set to 0, the record remains editable in the separate file. In DTData it is not editable. Committing the record in the separate file by clicking on the layout background and then attempting to edit the record makes the privileges behave as expected and the "Your access privileges do not allow you to perform this action." message appears.

      This is a security hole that allows the user to continue editing the record when they should no longer be able to edit it.

      Workaround

      Setting the global variable in the script in DTAdmin causes the problem for a reason I don't understand. If I disable the step that sets the variable, the problem doesn't occur. This seems like a rather obscure bug happening in the security of the file.

      I have an example file that I can provide to further illustrate the problem.