I see its possible to script user creation, where is this data being stored and how do I make use of this in a solution. e.g. does user exist, last time user logged in etc
no it's not possible. You might investigate external authentication, though.
if user logs in, then it exists.
Last time he logged - you must keep a log file in a table you create to achieve that.
What are you trying to do ?
Not trying to re-create the wheel if one already exists..right. But to learn more about what can be done with the built in security controls and leverage them in a solution if possible. I was thinking along the line of simple auditing
We script account creation, from a table called Accounts, via script. The accounts table itself includes additional information like the actual account holder name, contact info, etc. It does NOT hold the password; it's just a place to keep additional information about the account holder and a way for administrative users to add accounts without having a full access password.
We also have a Sessions table, which we use in the more conventional way, but since that's linked to an Account we can also use it to show login history and information about their sessions.
Some caveats and considerations:
So I'd say yes, it can be done, and in fact we do it. It does require some careful thought and scripting.
The advantage is that a non-fa user, but one granted permission to see accounts and run the account routine(s), can manage user accounts, adding them, resetting passwords, inactivating them, making changes, etc. This cuts us, as developers, out of that process except in rare cases that new priv sets need to be added, or fa accounts need to be managed, and it doesn't require extensive training for the responsible user. It's actually the reason I'm hesitant to go to external auth for smaller clients, where this works fine and there isn't generally a full-time IT staff to manage accounts.
Chris, thank you for that detailed reply. This really opens my eyes as to how to handle this side of the user equation.
There is an important distinction to be made between:Get ( UserName ) [local to the installation]Get ( AccountName ) [can be used to authenticate from different machines/installations] Both UserName and AccountName can be read using the Get functions shown above. AccountName, which lives under: File > Manage > Security... can be set/pushed into one or more files using Add Account, one of the Accounts script steps:• Add Account • Change Password • Delete Account • Enable Account• Re-Login• Reset Account Password If you know the user password (as you might in a multi-file deployment), you can automate the changing of a password for an existing set of file_accounts using the Change Password script step.In some cases it will be better to delete and add. The best method depends on the situation, tweaks that you might have made to a user account, etc. There is no script step for changing the privilege set that is attached to an Account. In that case you would Delete Account and then Add Account, or do it manually. Hope that helps. Tony Whitehttp://www.twdesigns.comhttp://FileMaker-Fanatics.com
I realise there's some confusion about what an account really is.
IMHO, what Filemaker allows via scripting, as wonderfully detailed by posts above, is actually the creation of a new user.
For me, a scriptable account creation means being able to create a user name + password AND a customised access to the database, which is actually not available in Filemaker.
I think you are wrong. In the list of script actions concerning accounts there is 6 solutions :
With all this actions, you can do everything you want.
bertrand wrote: I think you are wrong. In the list of script actions concerning accounts there is 6 solutions :With all this actions, you can do everything you want.
Which one allows me to create a new privilege set ?
siplus, this is true, but I don't know that priv set definition is something I'd want to turn over to a user, anyway.
Once the privilege sets are established, though, setting up a new user, activating/deactivating them, resetting their password, etc. is something I definitely want to turn over to management. For these items, the manager needs to know what department/role the user is in, but they don't need to understand relational databases and such.
Yes, you can't create a set of privileges set with script.
Is it when running solution that you have to build a set of privileges ? `
They must have been defined when building the solution or must be part of a new definition of solution.
Building a set of privilege is not a common operation, it must be prepared and tested. There can be a lot of problems coming from privileges bad working.
You can choose the set of privilege when you create or modify an account.
Of course not, but in one of our most important solutions, consisting of 54 database files, some having several tables, I have to create 20 new users, spread on 5 new privilege sets.
Definitely not scriptable, not copy-pastable, not calculated value assignable, useless. That's it.
Retrieving data ...