We’re excited to announce the release of version 1.27 of FusionAuth. This shipped on May 5, 2021, with follow on point releases in the following five days. This version resolves issues for FusionAuth community members and customers on versions 1.26 and older.
This release contained a number of enhancements and bug fixes. Please see the release notes for a full breakdown of the changes between 1.26 and 1.27.
There were a few items I wanted to call out.
Account email verification gating
This version has account verification gating. With this feature you can block a user from completing their login until they have verified their email address. This is a reactor feature, requiring a paid license.
You can learn how to set up email gating with this tutorial.
Application themes
You’ve been able to control themes at the tenant level for a long time. And you’ll continue to be able to do so.
Tenants are separate user spaces. But sometimes you want a common user base but with a different look and feel for the hosted login pages.
There were some half measures you could take. You could do some freemarker logic based on the applicationId. You also could perform some customization with JavaScript.
But with 1.27, you can create an entirely separate theme with all the customized templates. It is still manageable via the API. But you can configure an application to use it, and it will be used instead of the tenant’s theme, for this application.
This is a reactor feature, requiring a paid license.
Safe links in passwordless emails
FusionAuth supports passwordless authentication in a few different ways. In a common scenario, a user is sent a one time code to their email. When the user clicks, they are logged in.
This works well, but there are some network security devices and email clients, like Microsoft Outlook, sometimes request these links before the user can click on them. This is often done to address security concerns. This led to a bug where Magic links don’t work when Outlook “safe links” are enabled because the one time code is used up in the initial request, rather than when the user clicks on it. The user is then unable to login, which is a frustrating experience.
While this is a complex problem and every system may have subtle differences, this release contains a proposed fix that should help. If you have had this issue with FusionAuth in the past, please test it out and let us know. Please re-open it with details if you aren’t able to successfully use email based passwordless authentication.
Other enhancements and bug fixes
Some of the other enhancements included in this release are:
- Transparent unique username generation for your users (this is a reactor feature, requiring a paid license).
- An API to retrieve the current FusionAuth instance version.
- The ability to add or remove the
keyManagerattribute from an API key. - SAML v2 IdP Initiated Login works with an issuer that is not a URL (this is a reactor feature, requiring a paid license).
- The
user.data.emailproperty is fully documented and available. This allows you to use email features, such as email verification or password resets, for users without a unique email address.
And a whole lot more. In total, I counted 16 GitHub issues resolved in the 1.27.x releases.
Upgrade at will
The release notes are a guide of the changes, fixes, and new features. Please read them carefully to see if any features you use have been modified.
If you’d like to upgrade your self-hosted FusionAuth instance, see our upgrade guide.
If you have a FusionAuth Cloud deployment, proceed to the “Deployments” tab on your account dashboard and upgrade your servers. If you have any questions about the upgrade, please open a support ticket.
Or, if we’ve piqued your interest and you’d like to use FusionAuth, check out your options.
