FileMaker makes it too easy for developers to make updates to applications in production. This is a risky practice, and should be avoided as much as possible. Best practice is to have a separate development and production server, and migrate development changes to production in a version controlled environment, like GitHub. Sometimes, a critical fix needs to be pushed to production, without waiting for the next version to be ready to deploy. This is called a “Hotfix.”
This articles explains some best practices for managing applications on a production server without allowing full access accounts with access to production. Most IT departments will restrict Development accounts from having access to the application on production, for security, data integrity, and performance reasons. They will rely on tiered security, where a Development account cannot access the application until a Server Administrator turns on their access. While a Server Administrator has access to manage the accounts, they do not have access to edit any development or data in the application.
Developers with Full Access
The [Full Access] privilege set is required for a number of development action in FileMaker. It is required to update tables, fields, and relationships, to manage custom functions, privilege sets, and to save a copy as XML. Managing [Full Access] accounts can only be done by an account with [Full Access]. Most developers are going to need [Full Access] in order to make changes to the application. There is a subset of development activities that can can be delegated to a lower privileges set. Those are:
- Managing certain layouts
- Managing certain scripts
- Managing extended privileges
- Managing user accounts that aren’t [Full Access]
Migrating to Production
When migrating to production, all [Full Access] accounts should be turned off as a best practice for application security and integrity. This means if an issue arises in production, a developer is unlikely to have the access necessary to debug and fix the issue in production with a hotfix. This should only be utilized when there isn’t time to address the issue through normal development operations, and should be used with caution. Any fix applied to production must be repeated on development, otherwise the next migration will undo the fix.
In order to enable hotfixes, without leaving a [Full Access] account available online requires two accounts. One acts as the gatekeeper ( Admin ), and the other acts as the Developer with [Full Access]. The Admin can be a local account or a group account. Group accounts are authenticated on the server, and can’t open the application locally. The [Full Access] account should be a local account as a best practice, as group accounts could potentially be hacked by moving the file to a new server authentication infrastructure that the hacker controls.
Server Admin
We will assume the Admins are part of the IT Operations team, while the Developers are part of the IT Development team. The Server Admin is a privilege set that can be some variation of the [Read Only] account. They do not need any access to the file other than:
- Manage External Privilege Sets
- fmapp external privilege set
In the development environment, this Admin account should be assigned [Full Access]. This gives the IT Operations the ability and oversight to manage and reassign developer accounts to the application in the development environment in case developers leave or new developers are added. The account will be set to the Server Admin privilege set when moved to production.
Development to Operations
The process of moving the application from development to operations begins with the Developer letting the Server Admin know the file is ready to release to production.
- Admin logs into development with [Full Access]
- Admin verifies only the Server Admin privilege set can Manage External Privilege sets. This ensures that other users can’t activate the [Full Access] accounts in production.
- Admin sets a local [Full Access] account password. This account will be turned off in production, but is needed to save the account changes and migrate production data.
- Admin sets the Admin account to the Server Admin privilege set and saves the account changes using the local [Full Access] account just set.
- Admin migrates production data into the development file. In order to use verbose mode in the Data Migration Tool, the local [Full Access] account is required, as well as the fmdatamigration extended privilege set.
- Once in production, the Admin logs in to the application, now with the Server Admin privilege set. The admin removes the fmapp and fmwebdirect, and any additional ones not needed, extended privileges from the [Full Access] privilege set.
This last step is only needed if “ignore accounts” was selected in the data migration process. If it was not selected, then the new production file will have exactly the same accounts and privilege sets from the original production file.
Applying a Hotfix
Now the new file is in production. It turns out that some developer has accidentally left a feature flag set to true that should not be set in production. This issue was just discovered, and it is causing records to be saved incorrectly in production. This needs to be fixed immediately, the longer it takes the more records will be broken, and the fix is straightforward and understood. It can’t be fixed in development and deployed as an update because development is in the middle of a sprint and features are not complete or tested for deployment yet. This sounds like a job for Server Admin.
The Admin logs into the file on production with the Server Admin privilege set. This allows them to manage extended privileges and add the fmapp extended privilege to the [Full Access] privilege set. Now, the developer with the [Full Access] accounts can log in on production, set the feature flag to False, and save the changes. Once complete, the Admin logs in and removes the fmapp extended privilege set from [Full Access]. Production is saved and everyone gets a high five.
