One of the wonderful things about Claris FileMaker is its ability to power web apps. However, doing so brings up questions about authentication. For instance, how do you allow a user to securely log into a web app? Once they’ve logged in, how can information about the user be easily collected, displayed, and changed according to the user’s role and permission set in that web app?
For Next.js there is a great library to handle secure authentication: NextAuth. Because NextAuth is open-source and extensible, we built a FileMaker database adapter—Next-Auth FileMaker Adapter—that can connect directly to your existing solution and access various attributes that you are already storing about your users. In the tutorial below, you will learn how to configure a Next.js project with NextAuth and FileMaker.
To best follow along, you should be familiar with npm or yarn, the basics of Next.js, and how to enable the FileMaker Data API on FileMaker Server. Prefer to watch me do it? Feel free to follow along with this video!
Project Setup
For this tutorial, start with the example provided by NextAuth: https://github.com/nextauthjs/next-auth-example
NOTE: This example repo uses TypeScript, but there are no TypeScript-specific features required for this tutorial. It should look and function very similar to a standard JavaScript project.
1. Clone the repository to your computer.
git clone https://github.com/nextauthjs/next-auth-example.git cd next-auth-example npm install
2. Configure your local environment.
cp .env.local.example .env.local
Start by editing this file with some API keys to connect to whichever login provider you’ll want to use. You can learn more about all the available login providers and how to configure each one in the NextAuth documentation. If you go the Email provider route—a great option for password-less login links—you’ll also need to install the nodemailer package to your project npm install nodemailer. While you’re in the file, add credentials for connecting to your FileMaker server—you’ll use them later. If you’re using my sample file, add the credentials below to the .env.local file. This account has the fmrest privilege set enabled, and the file should be hosted on a server with the FileMaker Data API enabled.
FM_USERNAME=fmrest FM_PASSWORD=fmrest FM_DATABASE=next_auth_demo.fmp12 FM_SERVER=https://myfmserver.com
Remember to change the FM_SERVER value to your own FileMaker server, where this file is hosted!
If you have Otto installed on your FileMaker server, you can also use the Data API proxy feature instead of username/password.
3. Install the FileMaker Adapter.
Run the following command to add Next-Auth FileMaker Adapter to your project.
npm install next-auth-adapter-filemaker
4. Run the website locally.
This step ensures that you’ve got the initial setup working properly. If this step fails, go back and double-check all the configuration settings.
npm run dev
NextAuth Setup
With this project in your favorite code editor (I like VSCode), navigate to /pages/api/auth/[…nextauth].ts. Within the providers array, add or remove the login providers that you want to expose to your app, depending on which ones you set up in the previous step. Add the following code to the top of the [...nextauth].ts file (before the export statement):
import { FilemakerAdapter } from "next-auth-adapter-filemaker";
const fmAdapter = FilemakerAdapter({
auth: {
username: process.env.FM_USERNAME,
password: process.env.FM_PASSWORD
},
// or, if you have Otto on your FM Server
// auth: { apiKey: process.env.OTTO_API_KEY },
db: "FM_DATABASE",
server: "https://myfmserver.com",
});
Then, add an adapter key to the NextAuth export that references the adapter we just created:
export default NextAuth({
...
adapter: fmAdapter.Adapter,
providers: [...]
...
});
And that’s it! Run the dev server (npm run dev) and check out the example in your browser. When you log in, you’ll see your user account created in your FileMaker file.
Usage
One of the major benefits of this setup is that you can now easily access other custom attributes about your users as defined in your FileMaker file. Now that NextAuth can access your user table, you can inject that information into the session object that is returned. Within your NextAuth configuration object, add the callback function for session and inject the user object into session.user, then return the session object like so:
export default NextAuth({
...
callbacks: {
session({ session, user }) {
session.user = user
return session
}
},
...
});
By default, the user object that’s returned from the session is very bare-bones, but with this technique, the entire use object returned from your FileMaker database will be present in the front-end of your web app. Now, go to the nextauth_user layout in your FileMaker file, and change up the fields that you see there. You can remove any of the optional fields that you don’t need or add your own! After making those changes you can go back to the web app and re-fetch your session on the API example page to see all of those fields come through.
To see all of this in action, check out my video tutorial.
Optimizations
If you’d like to implement this in production, there are a couple more things to consider. The default configuration will make at least 1 Data API call to your FileMaker server each time that a new page is loaded, sometimes even more frequently. To counteract this, you have 2 options which I can describe briefly.
Option 1: JSON Web Token
If you change your session strategy to JWT in the NextAuth config, it will only use the adapter for login, but not sessions. To remain logged in, the user will store this special token in their browser. The primary downside to this approach is that you cannot force a user to log out by deleting their session on your server, but it is the simplest way to configure a production-ready app.
Option 2: Redis Cache
This package supports caching sessions in a Redis database so you can still get the benefit of database sessions without the load on your FileMaker server. At this time, we have tested support with the Upstash Redis host, as they have great serverless support and work well with Next.js
The primary downside to this option is that you’re now dealing with a cache, and that requires a bit more thought about how you might want to update user data since the web app will no longer hit your FileMaker database directly to check for the latest changes. The cache is automatically updated when a user logs in, but if you want to update any part of their user object while they are logged in, you may need to have FileMaker update the Redis cache directly.
Proof+Geist: Supporting Your FileMaker Ecosystem
At Proof+Geist, we know that the Claris platform is a key puzzle piece to any business ecosystem. With our world-class hosting platform, professional development tools, and expertise in both Claris FileMaker and web technologies, we are ready to innovate and help support your business. For questions, comments, or more information, drop us a line at info@proofgeist.com.