How much do you care about the security of that data in that file? Or the integrity of the file itself?
Why wouldn't you use either of those two options?
External Authentication is the only other option to using a default account in the File Options or using FileMaker Account Authentication. External Authentication relies on the network's system of user authentication, which varies with the OS.
Go to FMI's Knowledge Base at:
Do a search on "external authentication" for online help documentation from FMI.
I'm going to try and better explain my issue, try and bear with me. So the person I'm deesigning this for wants to have a log in script ONLY, NOT the FileMaker log-in. This is because he wants to have an option for a user to create a new account without having to enter the file as someone else that has privleges, create their account, and then be able to login.
The way he "sees" it working is like this: the file is opened to a generic log-in page. The user either has the option to log-in if they already have an account or to create an account if they do not. The login works by comparing email addresses and passwords to records already saved in the CRM that is tied to this program. To log-in, the password and email are saved as variables and compared to the respective record in the CRM, if it does not exist they cannot log-in, if it does they are in to our homepage customized to their account. If they do NOT have an account, WHERE I AM HAVING ISSUES, it takes them to a separate layout. Here they enter the email address they gave to the employee to add into our CRM then type in their selected password. When they are finsihed, they hit a button CREATE ACCOUNT that fires a script to create an account for them with that email address and password, creates the same account in our external data sources, and then runs the re-login script to put them in. However, I cannot do any of this if they have to be logged in before they can do anything.
Any ideas? Am I going down a misguided track here?
I'm sure others will speak to the wisdom of this approach, I'll just give you the rope. Please note, you should not be saving passwords in the file. It sounds like that's happening with the CRM.
Create an account that has access to *ONLY* a) your login layout and b) a global table which the login layout is based and c) 3 scripts: an OnFirstWindowOpen script, the login script, the create account script. Set the File Options to open with that account.
Someone opens the file and they're auto-logged into to this limited account. The FirstWindow Open script takes them to the login layout. The create account script needs be run with the "Run script with full access privileges" checkbox set.
There are some security weaknesses in this method. You'll have to decide if the tradeoff is worthwhile.
David Jondreau has you headed in the right direction.
My ideas and remaining questions are:
- Do you really need to create these accounts in the external data sources, or would it be better to let the external data sources open with defaults, but make all of the interface file (the first file where the account is verified/created) limited access based on having a valid account?
- I have used similar systems to what D.J. mentioned with files designed to be used by single users on local systems, but included a script step which, after creating the new account with access to the data, also removed the default account, so no one else could then open it once the single-user had set up their own account/password credentials. This made a password-secured single-user file even though no personalization had yet been made to the accounts when it left my hands.
- If this is indended for some on-line access, where you essentially want users to register, you don't even need accounts. You can set it up with a valid user table, have the scripts check that the user exists and has matched some pin-code/password in their own record, then set global variables which are used to control file access/security. If no record matches, let them create their own user record with their name/email and personal access code, then set the global variables to give them proper access using Record Level Access (RLA) via the Manage Security privilege group used for the auto login.