One very simple solution: use External Authentication.
If you want to stick to internal accounts the the most secure option is to have identical accounts in each file.
Thank you for the feedback. Unfortunately, external authentication is not an option on this project.
1 of 1 people found this helpful
Remember that you don't need AD or OD if those are not an option, you can use local accounts and groups on the FMS machine.
WIll External Authenication that is done from the FileMaker Server machine extend to FileMaker Go?
No, I was not aware of this, and it may be an option. I'll investigate. In the meantime - since a cannot risk my timelines - I built a custom account management system to meet my needs.
Any specific advice or resources on using local accounts and groups on the FMS machine? If I can move to a simpler solution in the future, I'd be happy to do so.
So on an iPad it would ask for a username and password that would authenicate to the FileMaker Server OS groups not FileMaker internal authentication?
When I have a solution using data separation, I will sometimes allow password-less access to the UI file (since there's nothing sensitive about the UI), and only set passwords on the Data file.
But the dialog would come up when the user gets to a layout requiring access or show the ugly UI <NO ACCESS>, right?
I still set passwords that are the same on both files. EA helps here! Open the UI file, it opens the others with the same privileges.
Sing along if you know the words: "It Ain't Necessarily So"
In the Data File, create a 1-line script, perhaps named "Authenticate":
- Exit Script [ Result: "Success" ]
In the UI File, the OnFirstWindowOpen script does the following:
- The user lands on a Splash Screen based on a local table, without records or fields for best performance.
- Set Error Capture On
- Perform Script [ "Authenticate" from file: "Your Data File" ]
- If [ Get ( ScriptResult ) ≠ "Success"
- Show Custom Dialog [ "Sorry Charlie" ]
- Exit Application
- End If
Why would you do that?
Why would your opening trigger call a script like that in another file?
Given that particular example, it isn't necessary, but I typically return the User Name and/or Privilege Set Name, and base layout or feature access on the results.
Thanks for the clarification, Marc!