A lot of attention in the FileMaker 19.6 release will undoubtedly go to the Transactions feature. However, there are some important changes to FileMaker Server as well, and we want to highlight these here for you.
- An Old Feature Brought Back: Administrator Groups
- Key-pair-based Login to the Admin API
- Sign in with Apple in Claris FileMaker 19.6
- Read-only Admin Console While Database Server is Stopped
- Facilitating Go-lives and Deployments in Claris FileMaker 19.6
- Second Additional Database Folder
- Monitoring & Troubleshooting Improvements
- Performance Improvements in Claris FileMaker 19.6
- Miscellaneous Changes in Claris FileMaker 19.6
- Moving Forward in 19.6
There are two noteworthy changes that are relevant only to the Linux version of FileMaker Server.
only Ubuntu 20.04 LTS
With FileMaker Server 19.5, you could pick either Ubuntu 18.04 LTS or 20.04 LTS; now, you need to use Ubuntu 20.04. If you are upgrading your server from 19.5 to 19.6, we suggest that you install Ubuntu 20 fresh instead of upgrading the OS from 18 to 20.
Ubuntu 20 LTS (Long Term Support) will be supported through 2030 with security patches and until 2025 with active updates:
The XML API is now available in the Linux version of FileMaker Server. That brings the Linux version closer to feature parity with its macOS and Windows siblings.
Bringing back the XML API is a surprise move, and it is unknown at this point what effect this has on the Data API allotment.
There is no setting on the Admin Console to enable the XML API. You have to make an Admin API call or enable/disable it from the Admin CLI. The XML API is off by default.
There are some other Linux-specific feature changes in the other sections below.
An Old Feature Brought Back: Administrator Groups
And speaking of old features: in prior versions of FileMaker Server up to and including version 16, you could specify groups of sub-administrators and assign them certain privileges on files hosted from a particular folder on your server. FileMaker Server 19.6 brings this feature back. You can give groups of people control over files, segregated by folder, without having to give out the master password of your FileMaker Server or adding them to a single External Authentication group that gives them access to everything.
There are some caveats:
- These groups only have rights to the Admin Console. Their privilege does not extend to the Admin CLI or the Admin API.
- If your server is on Ubuntu, you cannot use local accounts and local groups that exist in the OS of the server. While this works for macOS and Windows, it does not for Linux. This limitation is not just for sub-admin groups but for external authentication as a whole.
- When you let a group view the logs, they will see the full logs, not just log entries related to the files in their folder.
Key-pair-based Login to the Admin API
Along the same lines of providing access to a FileMaker Server without giving away the master password or adding someone to your external authentication group that provides full access, you can now use private/public key pairs to grant access and restrict the validity of that access to the Admin API.
This type of access is extremely well suited for any type of automation; however, it cannot be used for logging into the Admin Console or for taking actions through the Admin Command Line Interface.
This works as follows:
- One-time setup: You generate a key pair: a private key and a public key as well as a JSON Web Token (JWT) that is signed with the private key. That JWT contains the name you will use for this keypair and contains the number of days for which this token is valid.
- You upload the public key to your FileMaker Server and specify the exact name that you used to name your JWT (the name that is also embedded in that JWT).
- You hold on to the private key. It serves no further purpose except perhaps to regenerate the JWT if needed
- When you make the initial login call to the Admin API, you will use the JWT token in the Authorization header, prefixed with “PKI.“ The JWT is basically just a long string of characters.
How to Generate Those Keys and the JWT Token?
Your FileMaker Server has a new folder named Tools that has two Python example scripts (to generate the set of public and private keys) and one JWT token file.
Python is not installed by default on your Windows or Linux server, and I do not recommend installing Python on your server to run this code. Rather I suggest copying these python files over to a machine that has Python or where you can install Python.
You only need fmadminapi_pki_token_example.py. The other python file (fmadminapi_pki_request_example.py) is just to show how you can use the JWT token to log into the Admin API. Instead of that python file, you can use Postman or Insomnia, as shown above, to accomplish this more easily.
Admin API Changes
Besides the new method for logging into the Admin API with the PKI prefix and the JWT token, the Admin API has also been updated to list, add, change and remove key pairs.
Adding a new key requires you to send the name of the JWT token (remember that the name is embedded in the JWT token that you’ll use to log into the Admin API and it has to match exactly), and the public key part of the pair:
Note that when sending the public key through the Admin API, you need to remove all line breaks.
For some reason, FileMaker Server does not like the public key in its original format with line endings every 65 characters.
Sign in with Apple in Claris FileMaker 19.6
Still on the topic of authentication, FileMaker Server has a new addition to its list of pre-canned external identity providers: Sign in with Apple (SIWA).
The ability to use your Apple ID to log into your FileMaker solution is not new. In fact, over two years ago, Steven Blackwell and I authored a white paper that shows how to do this. After all, it is just another OpenID Connect/OAuth authentication flow.
The main difference is that this version allows for Apple’s Hide My Email. Well, at least to some extent as the user will still have to generate a random email ahead of time. That email needs to be added as an account to the FileMaker file before the user can log in using SIWA. This user experience is different than most other places where Hide My Email can be chosen as part of the login process.
More about this in a separate blog post.
- As with most external identity providers, the client secret (think: password) that allows interaction with the identity provider has an expiry date. With SIWA, that is a maximum of 180 days, after which you will need to generate a new client secret and update your FileMaker Server configuration.
- This feature requires you to enable the SMTP settings on FileMaker Server since Server has to email the user. If you cannot do that or have no desire to do so, you can still use the approach that Steven Blackwell and I outlined by adding Apple as a custom OAuth provider.
- Apple IDs are individual accounts; there is unfortunately no group-based login possible using SIWA. In that sense, it is the same as adding individual Google or Amazon accounts to your FileMaker solution and it is less desirable than group-based access.
Read-only Admin Console While Database Server is Stopped
Up to FileMaker Server 19.5, when you stop the Database server, the Admin Console stops displaying altogether in the web browser.
All you see is this:
In 19.6, the Admin Console remains visible so that you can navigate around and check your settings.
Note that you cannot change any settings when the Database Server is stopped.
If you are like us and find yourself needing to check a particular setting right after you stop the database server, you will quickly come to love this feature.
Facilitating Go-lives and Deployments in Claris FileMaker 19.6
FileMaker Server 19.6 now bundles the matching version of the Data Migration Tool. With that, you always have a place to grab it without having to scour the Claris website. This bundling allows you to more easily automate your deployment tasks that involve moving data between different versions of your solution files. You will find the DMT in the Database Server folder (or the /bin subfolder on macOS and Ubuntu).
Another feature that makes automating data migrations easier is the new –cloneonly (or -e for short) option to the fmsadmin backup command, and a matching option in the Admin Console itself when you create or edit a backup schedule:
Previously, to generate a clone of your files, you had to run an full backup with the clone option enabled. If your solution was big, that then took a lot of time and potentially a lot of disk space just to produce clones.
Now you skip the backup part and have FileMaker Server just directly produce the clones. If you run the command in its simplest form:
fmsadmin backup --cloneonly
Then your clones will be in a new ClonesOnly folder directly in the Data folder:
You can control the destination by using the existing destination -d or –dest option
Second Additional Database Folder
FileMaker Server 19.6 adds the ability to configure two additional database folders, each with their own remote container folder if needed.
Restrict access to the Admin Console
Ever since the Admin Console started using port 443 for remote connections, there has been an increased demand for the ability to lock down access to the Admin Console. This is primarily due to the fact that WebDirect and the Data and OData APIs use this same port 443. If you want to use those but do not want anyone trying to and log into your Admin Console, you can now easily whitelist which IPs should have access to the Admin Console and the Admin API:
Anyone else will see this error message:
- If you want to use multiple IP addresses, separate them with a comma
- Localhost access on the server itself will always work, regardless of this setting. You do not need to add 127.0.0.1 to the allowed list.
- You can also do this for older versions of FileMaker Server, but it requires you to modify the underlying config files. See the instructions in this Claris Engineering blog post.
The Admin API has also been updated to allow you to control these settings.
File-List-filtering as the New Default in Claris FileMaker 19.6
File-List-Filtering (FLF) is a feature that has been around for a long time. When you enable it, it will ask the user to authenticate first and only then show a filtered list of hosted files: those files to which this user has access (an active account in).
FLF is now toggled on by default in FileMaker Server 19.6.
And when you select the server from your list of Hosts, you will see a login prompt before you see any files:
The Admin API also allows you to control this setting. Assisted Install file now contains the FLF setting (and enabled by default) so that you can control the setting at installation time:
The Admin API’s /databases endpoint also honors this setting. When the filtering is enabled, you need to add credentials to the Admin API call to get data on any files.
OAuth Login Button and/or FileMaker credentials input
When you configure your FileMaker Server to support external authentication through an OAuth-compatible identity provider, then all files hosted on the server will show the identity provider’s login button – even if the file being accessed does not use any externally authenticated accounts. This has been confusing, especially since the default behavior of a file is to hide the FileMaker credential input.
19.6 is now smart enough to always show those FileMaker credential input fields when the file does not use any externally authenticated accounts.
The table below shows the possible combinations of how your solution’s files are configured and how FileMaker Server is configured, when it comes to what is shown on the file’s login dialog.
With file options in the left-most column we are referring to this setting, which is toggled off by default in FileMaker versions up to and including 19.5.
|What is shown on the login dialog?||FileMaker Server HAS OAuth Configured||FileMaker Server does NOT have OAuth Configured|
|File uses EA account and file options enabled to show FileMaker account fields||Both FileMaker login fields and IdP button||Only FileMaker login fields|
|File uses EA account and file options disabled to show FileMaker account fields||Only IdP button||Only FileMaker login fields|
|File does not use EA account and file options enabled to show FileMaker account fields||Both FileMaker login fields and IdP button||Only FileMaker login fields|
|File does not use EA account and file options disabled to show FileMaker account fields||
Only IdP button
<=19.6: Both FileMaker login fields and IdP button
|Only FileMaker login fields|
The change in behavior is that FileMaker Pro and Server 19.6 override the default behavior as set in the FileMaker file and FileMaker Pro will show the FileMaker login fields if the file doesn’t have an externally authenticated account if file itself is configured to NOT show the FileMaker login fields. This will avoid users getting confused by seeing only the Identity Provider’s login button but not being able to log into the file with it.
And related to this login experience, any new files created with 19.6 will now have the default option enabled that shows both the FileMaker account input fields and the identity provider’s button:
Data API No Longer Reveals the Version of FileMaker Server
The /productInfo endpoint is one that does not require authentication, and previous versions of FileMaker Server revealed what version of FileMaker Server was responding. This is information that can potentially be used to determine vulnerabilities.
In 19.6, the endpoint no longer returns this information:
HTTP Compression Disabled in Nginx
HTTP Compression can be a security risk and is therefore now disabled in Ubuntu’s Nginx web server.
Monitoring & Troubleshooting Improvements
We are big fans of all the logs that FileMaker Server keeps. We think it is unfortunate that some of the important ones like the stats.log, topcallstats.log, and clientstats.log are not turned on by default. These logs contain invaluable data to monitor your solution and users and are indispensable when troubleshooting.
One nice addition to 19.6 is that you can now download all the enabled logs at once instead of having to select each log individually. Downloading the logs includes both the current and any old logs.
Performance Improvements in Claris FileMaker 19.6
This new version of FileMaker Server makes some tweaks to improve performance in a few specific areas:
- Faster bitwise operations (NOT, AND, OR, XOR) by using hardware accelerator Streaming SIMD Extensions (SSE) for Intel processors and the ARM64 processors’ SIMD equivalent: Neon. This is basically tapping into hardware capabilities that were unused before. Some of this applies to internal FileMaker Server executions in addition to any bitwise operations we have in our solutions.
- The Java Web Publishing Engine has better CSS caching
- Parallel backups will now remember their backup sets after a server restart. This makes backups consistently faster since FileMaker Server can retain what it learns about what files are modified together.
- If your solutions have the Guest account enabled, then you may find that Login performance is improved.
- Viewing lists of records in WebDirect has been improved, both in performance and in user experience, to reduce UI flashing when other users manipulate records that are in your list view.
- Also in WebDirect, more users can access the same records with fewer issues loading records or dialogs boxes.
- If your company uses Nginx Plus for load balancing, then you can link that deployment with your Ubuntu FileMaker Server. This is for WebDirect only and replaces FileMaker Server’s own native load balancer.
- If you are using WebDirect in a setup with multiple workers, you can now generate an SSL Certificate Signing Request (CSR) directly from the admin console of any worker machine.
- There are new Admin API endpoints for allowing Data API plugins and retrieving information about configured plugins for that scripting engine.
Moving Forward in 19.6
There is a lot of updated and new functionality packed into FileMaker Server 19.6. Our team is here to help answer any questions and support your implementation of new functionality. Contact us to get started.