3 Replies Latest reply on Feb 9, 2017 9:30 PM by danielfarnan

    Stale Cached Permissions on Re-Login


      Product and version: FileMaker Server / Pro

      OS and version: Windows Server 2008 R2 (DB), Windows Server 2012 R2 (WPE/Client) / Windows 7 Professional SP1 (Client)

      Browser and version: Google Chrome Version 49.0.2623.87 m

      Reproducable: Consistent on WebDirect and FileMaker Pro Advanced (installed on Server or workstation).

      Description: Database has an auto-login using an account with minimal permissions ("Login"). Login has script execution limitations (can only execute specified scripts). Database subsequently logs in as another account based on user input ("User"). User has execution permission for all scripts. When attempting to execute a script under User after re-login, if script was NOT permissible under Login, returns error code 9.

      How to replicate:

      Scripts: ScriptA, ScriptB, ScriptC

      Accounts: Login (execute ScriptA, no access ScriptB/ScriptC), User (execute all scripts)

      Steps: Log in as Login. Re-login as User. Attempt to execute ScriptA, executes normally. Attempt to execute ScriptB or ScriptC, returns error code 9.

      Workaround: Enable executable permissions for Login account for all scripts and enforce permissions manually in non-permissible scripts.

        • 1. Re: Stale Cached Permissions on Re-Login



          Thank you for your post.


          I am unable to replicate the issue.  This is what I have done:


          1. Using FileMaker Pro 15.0.1, I created a database file with one text field "Name".

          2. I added one record and set Name to "TSGal"

          3. I created three scripts: Script A, Script B, and Script C.  All three scripts execute the script step:

              Show Custom Dialog [ "Script <A/B/C>" ]

          4. I created a fourth script, "Re-Login" that uses the script step:  Re-Login [ With dialog: On ]

          5. I created an Account Name "User" with the following privileges:

            Records: View only in all tables

            Layouts: All view only

            Value Lists: All view only

            Scripts: Custom privileges... where all four scripts are set to "executable only".

            Available menu commands: All


          6. I created an Account Name "Login" with the following privileges:

            Records: View only in all tables

            Layouts: All view only

            Value Lists: All view only

            Scripts: Custom privileges...  where only "Script A" and "Re-Login" are set to "executable only".  "Script B" and "Script C" are set to "no access".

            Available menu commands: All


          7. Returning to Browse mode, I checked all scripts, re-login with other accounts, and everything appears as it should with "Login" Account Name only showing the scripts "Script A" and "Re-Login".


          8. I set the file for Network Sharing and WebDirect access.

          9. I uploaded the file to FileMaker Server 15 running under Windows Server 2012.

          10. I accessed the file via FileMaker Pro 15.0.1.  All works as expected.


          11. Under Windows 7, I launched Chrome 52, and accessed the hosted file via WebDirect.  Logging in with "Login" account only displays "Script A" and "Re-Login" scripts.  "User" shows all four scripts.


          12. I also check under Internet Explorer 11, and also with Safari and Chrome under Mac OS X 10.11.6.


          Let me know what I am doing differently than you so I can replicate the issue.



          FileMaker, Inc.

          • 2. Re: Stale Cached Permissions on Re-Login

            I believe I am experiencing the same issue. My setup involves a single file created on a Mac with FMPA that is set to automatically login as [Guest] and run a startup script, "Login Management", that performs the following steps:


            1. Clear two global fields and reset a global variable that acts as a counter

            2. Take the user to a login layout where the two global fields are available and pause to allow data entry

            3. When execution resumes (from a button on the layout), use an SQL call to check the values entered match a record in the users table - if no match, update the counter and loop back to the point in the script where execution pauses. If more than three attempts are made, show a different layout and then exit the application.

            4. Based on the group the user is in, either automatically re-login as the account name that matches the group name or (if a member of the Developers group) re-login with the dialog and then go to a different layout.


            What I have experienced:

            This process works when I have the file open locally on the Mac - once I remembered to set the script to run with full access privileges. I uploaded the file to my developer copy of FMS, running on Windows Server 2012 R2, and opened the hosted file with FMPA on my Mac. After being presented with the re-login dialog I am then shown an error dialog stating that I do not have the necessary permissions to perform the action.


            What I have tried:

            I first tried splitting the re-login process into a separate script called from the "Login Management" script and only made the separate script run with full access. This did not work.

            I then added a "Show Custom Dialog" step that displays the result of a Get ( LastError ) call. This gives a 0 on my local machine and a 9 when the same file is hosted.


            Making changes to this file involves closing and removing the hosted file using the admin console, logging in to the local file and then uploading to the server via FMPA.


            All user accounts are defined in the FileMaker file, I have not (yet) hooked up to a directory service. FMS is using the default security certificate.





            Any thoughts?

            • 3. Re: Stale Cached Permissions on Re-Login

              A few more things:

              I also have tried placing the file in the default directory rather than a folder on the host - no difference in the encountered behaviour.


              The process works for the user accounts that automatically login to any of the accounts with limited permissions. The process only seems to fail for attempts to log in to the [Full Access] account.