There is no way to import user accounts or priviledge sets. You are correct in your assumption that commercial software developers using FileMaker Pro need to deal with this issue when creating updates.
In my current practise, I have created what I believe may be a solution. It is complex.
You can create a user account with the Add Account script step. It allows you to create an account with an account name and password. Theoretically, this would allow you to create records with user names and passwords. With the help of an upgrade script, you could re-create each account during the upgrade process.
I say theoretically because if you use this approach, there is a security risk. It is considered bad practice to store user passwords in a field as plain text. Yes! There are some practicle reasons why you may want this. However, it may be possible for someone to gain access to the passwords stored in the user database.
The solution to this issue is to store an encrypted version of passwords in fields. During the upgrade process, the password would be temporarily decrypted to create the account with the user's current password.
This approach requires you to create an account management feature into your solution. All account creation, activation, de-activation, removal, modification and password change would need to be managed. Otherwise, your solution will not know which account exists or what is the current information of each account.
Thanks for the speedy and clear response, David. Even replies that start with "There is no way..." are a great help, as at least they stop me wasting time on something that I now know can never work. With absolutely no attention to detail on my part, you've made me think now along the lines of adding to my 'Add Account' and 'Delete Account' scripts with steps that log the changes. Then I can print them out and at least have a listing of the data entry work I have to do.
I'm not that fussed about the password security bit, though that's only because of my low expectation to start with: I sort-of assumed that at the very best I would have to set all passwords back to be the conversion-default 'Account Name', or an arbitrary '1234', and then insist that each user changes them again at log-on.
At least I know that when I'm sitting there doing, 'Click...click...import...click..OK...Manage...type, type, type... etc", that no-one will come along behind me and say "Why on earth are you doing it that way? Didn't you know...?".
I've been following this thread and wishing there was a better way. I think we should all retire to the Feature Request Form: http://www.filemaker.com/company/feature_request.html and make a few suggestions.
Two possibles come to my mind:
- An encrypted storage option for data fields.
- An import accounts tool for moving accounts and privileges info from one file to another to better facilitate system updates similar to how we can import scripts, tables etc.
Note: an "Import Accounts" tool need not access nor replicate existing passwords. A fairly secure approach would be to enable an import that pulls in account names and privilege set names/settings but resets all paswords to a specified default password. After the update, each new user would then be required to specify a new password on Log In.
I don't see why there has to be an issue about the encryption of passwords. The encrypted password has to be in the 'users' version of the file somewhere, and an Engineer in Filemaker knows where (even if they don't know what it is), so when we import data why can the import sequence not include a re-mapping of Account Names, Privilege Sets, and Passwords? Or at least an option to use 'Source or Destination' versions? They were encrypted in the user's file and could be transferred as such into the clone. As an 'outsider' I had certain access to their password (ie: I could not see it, but I could change it) and that level of access would be no better nor worse when imported to the clone, or when I opened their file with 'Admin' privileges (which I would have to do now.).
I think setting the passwords to '1234' and enforcing a 'Change next log-on' would be an unnecessary weakness on Filemaker's part: if I was a devious-enough user to want to pry then I could wait for the next release of the file and try and quickly log on as my manager (whose user name I could easily have seen) and log on with '1234' or whatever. I can't see why there would be any need for that compromise.
The more I think about it, the less I can see why importing the users version of Account Names etc is not the default position to take. Now that I've realised this characteristic, I've got two nightmares: one is that only 2 sites take up my solution. The other is that 2,000 sites take it up...
Thanks for the feedback; I like your idea about the Feature Request.
FileMaker Pro does not store passwords.
When you create or change a password, it is first encrypted in such a way that it is impossible to reconstitute the unencrypted password. The encryption algorithm is a one-way process - it can only produce encrypted results. It is the encrypted result, known as a digest, that is stored.
When you log in, the password is encrypted the same way as when you created or modified your password. FileMaker Pro then compares the result with the stored digest. If these match, then FileMaker Pro knows the user entered the correct password.
Thanks, David and Phil - but does that not mean that FM could simply import the previously-generated digest, effectively as 'the password'? You can see you've gone beyond my understanding, but I understand the end conclusion - thanks for your help. Because you stopped me going off and wasting my time I've simply added a step to the Add/Delete Account scripts to have them maintain a list of custom Account Names by adding or removing the Name each time. At the very least the Local DBA just has to print this list and then manually create them again. It shouldn't be too onerous, and it completely gets around the need otherwise to release top-level access, or for me to be there in person.
Pending a better solution from Filemaker, I'd call that a 'result'.
Sorry to take so long to see your response: I took your advice and posted a request - just not as well-worded as your own! Meantime I've implemented (still testing) the idea inspired by what was suggested:
- provide scripts to allow local DBM's to Add or Delete Account Names
- use the scripts to maintain a return-separated list of the customised users
- upon upgrading, loop through the maintained list and re-create custom-added users
I recognise that I have to maintain a list for users added to each Privilege set, as I can't see any way to define the Privilege set by calculation.
And I recognise that I am (or my 'clients' are) still left with the problem that the Account Names are created correctly but the passwords are back to being the default that I (re-)assigned.
Thanks for your help,
Although you can not define the priviledge set by calculation, you can script the re-creation of accounts.
In your users table, add a field for the priviledge set. In the account re-creation script, make an if statement for each priviledge set. If the user's priviledge set matches the if statement's, then create the account with the priviledge set using the calculated user name and password.