8 Replies Latest reply on May 10, 2016 6:04 AM by TSGal

    Client/Server inconsistent behavior in record access calculation

    kalle_samuelsson

      Summary

      Client/Server inconsistent behavior in record access calculation

      Product

      FileMaker Server

      Version

      11

      Operating system version

      Windows 2008 Server, Windows 7

      Description of the issue

      To control user record access privileges I load a user_id (number) into a $$variable in my database file startup script. In "Manage->Security" record access is set to "Custom Priveliges". View, Edit and Delete privilege is granted to users where the user_id value in the $$variable match a numeric field in each table.

      In effect, if the user created a record he may also view, edit or delete it.

      Behavior is as expected when running locally on a client but if the database file is hosted on a FileMaker Server the privilege-calculation partly fails. Viewing, editing and deleting records works well but searching for records returns error 401, no records found. This also includes quickfind.

      In effect, if the same search is performed on the same file, results is inconsistent depending on if the file is run locally or remote from a server.

      I´m not quite sure as to why this "error" occurs but it seems 100% reproducible. A guess is that the server evaluates values from local $$variables differently?

      Is this considered a bug or did I miss a section of the server manual?

      Steps to reproduce the problem

      - Create a new database.

      - Add 2 fields to a table, atleast one should be typeof number. I will call it "numberfield".

      - Add a few records with dummy data but make sure there are a few duplicate values of "5" the the "numberfield".

      - Create a new script that sets a $$ script-variable to 5. Make this script run at file startup from File-Settings (or just run it manually later).

      - Goto "File->Manage->Security".

      - Set a password for account admin ;)

      - Goto tab "Privilege Sets" and create a new set called "limited" or similar.

      - Set "Records Access" to "Custom privileges" and set the following access rules:
      View (Limited):  numberfield = $$user_id
      Edit (Limited):  numberfield = $$user_id
      Delete (Limited):  numberfield = $$user_id

      - Set Access via FileMaker Network (fmapp)

      - Goto tab "Accounts" and create a new user account called "user" or similar and give it access trough priveligeset "limited".

      - Click OK out of all dialogs.

      - Restart the file or re-login to log in as account "User" (make sure that $$user_id is set to 5)

      You should now be logged in as User and only have access to records where the value 5 exist in the field "numberfield".

      - Perform a simple search in one of the fields. This should return records as expected.

      - Move the database file to a FileMaker Server and open it (don´t forget to allow sharing for all users)

      - Open the server hosted file in the same client and log in as user.

      - Perform the same search. It should now return "No records found"

      Expected result

      I feel that the same search should return the same result regardless if the file is hosted on a server or beeing run locally on a client.

      So the expected result should be the amount of records that the user have access to or atleast the records that carries the value 5 in the numberfield.

      Actual result

      No records found when run on a server

      Configuration information

      I run this on FileMaker Server Advanced 11.0.99 (v1) and FileMaker Pro Advanced 11.0v2. I will install v2 of the server but judging from the releasenotes no changes is made to security?

      Workaround

      There is a workaround for finding all records where the user have  access.

      - Enter find mode
      - Set a field to equal-sign =
      - switch "matching records" from "include" to "omit"
      - perform find

      This will omit all records with "empty" values and thus showing all records where the user have access. This however does not solve if the user wants to perform a search for a specific value.