11 Replies Latest reply on May 7, 2016 8:05 AM by siplus

    Can this be done...


      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

        • 1. Re: Can this be done...

          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 ?

          • 2. Re: Can this be done...



            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

            • 3. Re: Can this be done...

              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:

              • You cannot add/update a full access account. Our process is to create the account using the scripted process with a lesser priv set, then as fa users go into manage security and upgrade the account. On login, if the actual priv set doesn't match the priv set on the Account record, the actual one "wins" and the account record is updated.
              • You'll need fields for username, priv set and active status. For each, you'll need the current value and the posted value. When you create/update the account, copy current to posted.
              • You can't abstract the priv set in the add account script step, so you'll need some else if's.
              • You can't change the password for an existing account, so the real process is to delete the posted account and create a new one.
              • We require an email address for the account holder, and send an initial, random password via smtp, so the administrator doesn't ever see it. We then require the account holder to change their password on first login.


              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 Cain


              1 of 1 people found this helpful
              • 4. Re: Can this be done...

                Chris, thank you for that detailed reply. This really opens my eyes as to how to handle this side of the user equation.

                • 5. Re: Can this be done...

                  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 White

                  • 6. Re: Can this be done...

                    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.

                    • 7. Re: Can this be done...

                      I think you are wrong. In the list of script actions concerning accounts there is 6 solutions :

                      Add account

                      Suppress account

                      Initialize password

                      Modify password

                      Activate account



                      With all this actions, you can do everything you want.

                      • 8. Re: Can this be done...

                        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 ?

                        2 of 2 people found this helpful
                        • 9. Re: Can this be done...

                          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.


                          Chris Cain


                          2 of 2 people found this helpful
                          • 10. Re: Can this be done...

                            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.

                            1 of 1 people found this helpful
                            • 11. Re: Can this be done...

                              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.