Collaborative software is on track to become a nearly $53 billion* industry by 2032. Needless to say, adding collaborative, multitenant features into your application will position you to capture a piece of that revenue.
In recent articles, we’ve covered how Supabase’s architecture relies on Postgres RLS to secure data within the database. While team-based features can be complex to implement, Clerk’s B2B tools integrate seamlessly with Supabase, enabling multi-tenancy with minimal configuration changes. In this article, you'll learn exactly how the integration works.
To follow along, you should have a general understanding of Supabase and ideally have built an application with Clerk and Supabase. If you want to learn more about the integration, we have an article explaining how Supabase Auth works and how Clerk can be used with Supabase.
Clerk simplifies authentication and user management implementation, including team structures and granular permissions.
By enabling the Organizations feature in the Clerk dashboard, you empower your users to create teams where they can invite other team members to collaborate. Admin users can also manage roles and permissions at the individual user level, ensuring each user has the proper level of access.
Clerk applies its signature component-driven design to organizations management, offering pre-built UI elements that streamline team permission workflows.
One such component is the <OrganizationSwitcher />. By adding a single line to your codebase, you get a beautiful drop-down that allows users to create and manage their organizations associated members (if they have the administrator role).
Supabase identifies the party making a request by parsing the claims of the incoming JWT.
For example, the following JSON represents the claims of a Clerk user making a request to Supabase, with the sub value representing the user ID:
By setting an active organization for that user (using the <OrganizationSwitcher /> or any other method), that user’s claims are modified to include information about the active organization in the o object, including the organization ID. The below claims represent a user with an active organization to compare how it differs from the above claims:
Our Supabase integration guide walks you through using the auth.jwt() function to extract the sub value from the JWT claims of the user making the request. This same function can be used to access the id value of the o object as well.
Consider the following RLS policy that restricts users to accessing their own records in the articles table:
Updating the using statement as follows will reference both the sub and o.id values. When combined with coalesce, the policy will first check the o.id claim and fail back to the sub claim if o is unavailable (indicating that the user doesn’t have an active organization selected):
If you need to create a number of RLS policies, constantly duplicating code to check for both the sub and o.id values can leave some room for human error. An alternate approach to simplify your policies would be to create a dedicated function that checks both values, returning the first available value.
The following snippet can be pasted in the Supabase SQL Editor to create that function:
Once created, the function can be used in your RLS policies like so:
You are welcome to modify the name of the function and relevant column names (I’m partial to owner_id) but this small change allows Supabase to automatically use the active organization, if set, with no further changes to the database while falling back to the user ID.
To demonstrate, let’s walk through an example using Quillmate, an open-source writing tool built with Next.js, Clerk, and Supabase. If you want to follow along, clone the article-add-orgs branch from GitHub and step through the readme to get the project running on your computer. Otherwise, feel free to continue reading.
Start by enabling organizations within the Clerk Dashboard by heading to Configure > Settings, then toggling Enable organizations. This simple toggle that enables the use of the organization components with this application.
Next, add the <OrganizationSwitcher /> to the sidebar near the bottom. This example also includes the showOrgSwitcher flag to the component props to indicate that the sidebar is used within a route for organizations. This will allow the sidebar to be used with URL-based organization switching, which is a method of setting the active organization by using the organization slug directly within the URL.
Update the src/app/(protected)/components/sidebar.tsx file to match the following:
Within the application, I now have this new dropdown where I can create an organization and invite others to it:
Next, create a migration to add the requesting_owner_id function to the database and replace the existing RLS policies to use the function.
Run the following command in the terminal to create the migration file:
This will create a file in the supabase/migrations directory with the support_clerk_orgs prefix. Add the following SQL to that file:
Finally, apply the migration to the database by executing the following command in your terminal:
With the above changes in place, it's time to test by creating an “article” (which is the main entity of Quillmate) in your personal account and an organization.
Start the project by running the following command:
Open the application in your browser using the URL displayed in your terminal. Note how the <OrganizationSwitcher /> displays “Personal account” to indicate that you do not have an active organization selected.
Click the New Article button in the sidebar to create an article while in the personal account to populate the database with some data. The editor supports markdown syntax and setting an H1 will automatically set the name of the article in the sidebar.
In my environment, I have a single article named “Hello world” in this tenant:
Use the <OrganizationSwitcher /> to create an organization and switch to it. Your list of articles should be blank - create another article here as well.
In my environment, I have a test organization named “D2 Frontiers”, where I have a completely different article. This is because Supabase is returning all records with an owner_id that matches the value of the o.id value in the claims:
Next, access the organization settings by opening the <OrganizationSwitcher /> and selecting Manage in the header. Navigate to Members and invite another user so they can access the application as well. I recommend using an alternate email address if you have one.
As an example, I’ve switched to a completely different user account that also has access to the “D2 Frontiers” organization and can access the same article!
Back in the database, the values in the owner_id column are different depending on the owner type.
Note that the article created with my personal account starts has an owner_id starting with user_ and the one created with the organization active starts with org_:
Using Clerk with Supabase unlocks multi-tenancy and team-based functionality in your application in a matter of minutes with just a few small changes to the code. This empowers your users to create their own groups where individuals can be invited to collaborate within your application.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。