We recently released version 1.53.0 of FusionAuth. As we continue our work toward simplification and a better user experience, we’ve added some hotly-requested features. Marching forward with our animal-based naming convention, I hereby dub version 1.53.0 The Login Lambda Llama.
Lambda-Based Login Control
Sometimes you need fine-grained control of an authentication. Here are some examples:
- A person who is a member of one group, but not of another. Weekday access to an application depends on being in both groups.
- You want to require all users who are logging in to use SAMLv2 and disallow any other kinds of login.
- Users of the Hooli application must have a
hooli.comemail address, while users of the Pied Piper application can have ahooli.comor apiedpiper.comemail address.
In a scenario like these, you need more than a login failure. After all, their login information may be correct, but they just don’t have access to that application. You need to be able to apply some level of logic to their authentication event. That’s where login lambdas come into play. You can find a high-level overview of lambdas inside our docs.
This is an addition to our long list of lambdas, which all add flexibility and extensibility to the FusionAuth login experience.
In this release, there is a new lambda that runs at the moment of login. This lambda returns a list of themeable error messages. If the list is empty, the login process continues. If the list contains error messages, then the login fails and your users are presented with the error messages.
This kind of flexibility should help developers use any kind of business logic to prevent unwanted access to their applications. When combined with Lambda HTTP Connect, you can even call out to external APIs and re-use existing business logic to allow or deny access.
Webhook Event Logs
If you’ve used FusionAuth, you know we love webhooks. With over fifty different events, you can use these to share data or affect user login or creation workflows.
But hey, we aren’t perfect! One flaw is that webhook events are not persistent within FusionAuth. This means that you couldn’t view a historical record of events and their responses, which would be extremely useful for troubleshooting or reviewing history.
Version 1.53.0 fixes this problem by adding a webhook event log. Now you can go back in time and see what webhooks fired and when. Since we haven’t invented time travel, this will only go back to the date that you upgrade to version 1.53.0, but it should help you with webhook usage and debugging going forward.
All the Rest
There’s more! We’re updating to Java 21, we’ve spent a lot of time optimizing FusionAuth for performance, and miscellaneous bug fixes as well. You can get all of the details about this and much more in our Release Notes.
If you’re not using FusionAuth, why not? We’ve made it easier than ever to kick the tires. Just choose a plan and enter your email. There’s no credit card required to get your trial started.
