If the contacts list is in filemaker then match an entered username to a username in the contacts list table.
Using a "Global" table to store access permissions would work fine, once the user has logged in set the permissions globals. On filemaker server Globals are session based and are unique to each user so that works well.
Have an "on opening" script to make the file open up on the log-in page and prevent the user from doing anything until they have correctly logged in.
check out modularfilemaker.org.. they have a security module that may fit your needs
using a table to validate is like internet securty, which is fine;
But, it seems like I have to go to a home page, do one login, then do an "advanced" login using like email and password.....
- how does one avoid this double login?
- how would you SET a security level in a scripted environment like this?
1) To avoid double log-in then ignore the filemaker user account login. Just have the file use a default "user" account privilege. File->File Options->"Log In Using"
2) Set security levels or access via checkmarks in the table. E.g. to restrict sensitive staff information set a "Staff" access privilige and test that when required
One VERY important warning regarding using globals for security. A somewhat proficient user, could potentially alter the globals values. If you are talking Global Variables, this is a HIGH risk, and you should not be using Global Variables for security. If you are talking Global fields, it's a little harder to do, but still possible, especially if your security model is not optimized to prevent access to the field...and you understand when certain settings in scripts, etc, open up access to those fields.
...then I'd set globals like cookies to keep track of them and as match fields to filter what the user could and could not see.
Storing a pseudo-account name in variable and using a general role-based account for security may not be a bad idea. Again, just make sure you fully understand the risk.
- How would a user alter a global variable such as $$userRightsLevel?
- Is there a way to script creating an account from a generic login, assign all new accounts "read only?"
- ie "lookup to see if this email is in the database; if so, create a username with that email and set to "read only". Later, the admin can grant higher rights. then the user logs in later with their email in accounts, and we run a script to pull their ID
- Is there a way to pull user rights via SCRIPT from user accounts, or do they need to log in directly to the user accounts FIRST.....
- One of my goals is to set $$userID which upon loading any record (mortgage loan data) would run a script deciding "is this user's ID listed as OK to see this loan file?" -- Is there a way to have a script on EVERY layout/record request which gateKeeps whether a user can go to that layout or see that record/field?
Thanks --trying to get security RIGHT.
1. Access to global variables is easy using FileMaker Pro Advanced - turn on the Data Viewer.
2. Yes, this is possible. I played around with such a system a few years ago; the database would default to logging in as a guest account with extremely limited access and the "new user" process included a script run with full access privileges to create the new account with a restricted privilege set. Administration is incovenient but manageable - especially if you have the system send an email when the new user account has been created.
3. If you create an account for each user, you don't have to worry about pulling an ID from a separate table. Or, if you must, make the privilege set assigned to general users treat the contacts table as restricted: a user account can only access records where the login account name matches the account name stored in the record.
4. Not sure what you're asking here. You can probably determine the privilege set assigned to an account via script without having to log in under that account - investigate the Design and Get functions in the calculation dialog.
5. You would be better off handling this through privilege set configuration. For example, you store the logged in account name when a record is created, and you have the privilege set defined so that only a user logged in with that account name can access that record. You could also store the privilege set associated with the account that created the record, and let anyone with that privilege set access the record.
I strongly recommend investing the time in defining your security requirements and studying the way built-in security works in FileMaker. It took me a good long while to get my head around it (if indeed I understand it fully), but now I find it a lot easier to build a robust solution.
• How would a user alter a global variable such as $$userRightsLevel?
With a copy of FMAdv it is as simple as opening the data viewer and editing it. With FMPro it can be done via scripts.
• Is there a way to script creating an account from a generic login, assign all new accounts "read only?”
yes. You can have auto-login set for a low level account. Have an workflow that allows existing users to login via the ReLogin command or let new accounts be created using info the user provides
• Is there a way to pull user rights via SCRIPT from user accounts, or do they need to log in directly to the user accounts FIRST…..
All the tools work on the current user, so they must login. You can track user rights in a user table but you cannot set extended privileges or user access privileges by script.
• One of my goals is to set $$userID which upon loading any record (mortgage loan data) would run a script deciding "is this user's ID listed as OK to see this loan file?" -- Is there a way to have a script on EVERY layout/record request which gateKeeps whether a user can go to that layout or see that record/field?
Look at user access privileges. You control the user access based on the privilege set that applies to them. These are group/role based privileges.