This content originally appeared on Bits and Pieces - Medium and was authored by Paul Rosset
Introduction
When it comes to choosing your stack for your next SaaS project, NextJS is a must choice in the react ecosystem, NextJS also make a good match with supabase.com/ an Open source firebase alternative.
In this post, I will show you how to integrate the supabase auth logic in NextJS in an idiomatic way.
Setting up a custom `App`
First, we will need to create the pages/_app.tsx .
This will allow us to create reusable logic among our App.
In this React Component page, we will use the SDK provided by supabase to handle authentification.
// pages/_app.tsx
import { supabase } from "../../utils/supabase";
function MyApp({ Component, pageProps }: AppPropsWithLayout) {
supabase.auth.onAuthStateChange((event, session) => {
fetch("/api/auth", {
method: "POST",
headers: new Headers({ "Content-Type": "application/json" }),
credentials: "same-origin",
body: JSON.stringify({ event, session }),
});
return (
<Component {...pageProps} />
)
}
This piece of code will allow performing a POST HTTP request to our future API route pages/api/auth.ts with metadata event and session an object that contains key pieces of information (auth cookie) about the user who is logged or not.
We are listening to any changes that could happen related to authentication (sign in, sign out, etc…) thanks to the supabase SDK auth. Once an event happens, we will immediately tell the server-side that the auth state has changed, then the server-side will update his state accordingly.
The good news as said earlier is that supabase is open source, which means that you can check what’s going on under the hood. For our use case, the logic happens here.
Setting up API Route Auth
Once the client is ready to send the event and session events, we need to create the function server-side that will receive that payload to interpret it.
// pages/pages/api/auth.ts
import { NextApiRequest, NextApiResponse } from "next";
import { supabase } from "../../utils/supabase";
export default function handler(req: NextApiRequest, res: NextApiResponse) {
// Set the auth cookie.
supabase.auth.api.setAuthCookie(req, res);
}
We are using again the supabase object that gives access to the set of API related to auth. setAuthCookie is using the under the hood theSet-Cookie HTTP header that allows the user agent to store a cookie that will be used in a near future.
We are already almost done!
Protecting routes
We now have the ability to protect our route thanks to the getServerSideProps function of NextJS.
// pages/protectedRoute.tsx
import { GetServerSideProps } from "next";
import { supabase } from "../../utils/supabase";
const Protected = ({ user }: IProps) => {
return <div>JSON.stringify(user)</div>
}
export const getServerSideProps: GetServerSideProps = async ({ req }) => {
// Get our logged user
const { user } = await supabase.auth.api.getUserByCookie(req);
// Check if the user is logged
if (user === null) {
// Redirect if no logged in
return { props: {}, redirect: { destination: "/auth/login" } };
}
// If logged return the user
return { props: { user } };
};
export default Protected;
The function is really straightforward, it will look in the cookie of the request if there is any auth cookie available to consume.
If an auth cookie is present, the function will fetch the user associated with the cookie from the backend and return his metadata.
On the other hand, if no auth cookie is detected, the API will not be able to fetch that user and then return null value, to indicate it.
Then, once we have our result, we will use the special API that getServerSideProps is providing, by either redirecting the user to the login page before he could reach the client rendered or making him access to the page asked with the desired props.
Then, that getServerSideProps function should be replicated to every page your application logic ask for it.
You can even do the inverse, for example when an already authenticated user navigates to the login page. You can redirect him to your main protected page instead.
Conclusion
It exists either the server-side way of doing it or the client-side way.
It’s generally a better approach to do it server-side way whenever possible to avoid a few edge cases where the application could behave wrongly.
Everything on the client side could be reached, so it means we should never trust the client side.
On the other hand, on the server-side, it is way more secure and hard to tweak.
I hope you will find it useful!
And do not hesitate to comment on this :)
Build composable web applications
Don’t build web monoliths. Use Bit to create and compose decoupled software components — in your favorite frameworks like React or Node. Build scalable and modular applications with a powerful and enjoyable dev experience.
Bring your team to Bit Cloud to host and collaborate on components together, and speed up, scale, and standardize development as a team. Try composable frontends with a Design System or Micro Frontends, or explore the composable backend with serverside components.
Learn More
- Building a Composable UI Component Library
- How We Build Micro Frontends
- How we Build a Component Design System
- How to build a composable blog
- The Composable Enterprise: A Guide
- Meet Component-Driven Content: Applicable, Composable
- Sharing Components at The Enterprise
Setting up Server Side Auth with Supabase and NextJS was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Paul Rosset
Paul Rosset | Sciencx (2022-06-02T21:49:53+00:00) Setting up Server Side Auth with Supabase and NextJS. Retrieved from https://www.scien.cx/2022/06/02/setting-up-server-side-auth-with-supabase-and-nextjs/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.