• Blog
  • Documentation
  • Courses
  • Changelog
  • AI Starters
  • UI Kit
  • FAQ
  • Supamode
    New
  • Pricing

Launch your next SaaS in record time with Makerkit, a React SaaS Boilerplate for Next.js and Supabase.

Makerkit is a product of Makerkit Pte Ltd (registered in the Republic of Singapore)Company Registration No: 202407149CFor support or inquiries, please contact us

About
  • FAQ
  • Contact
  • Verify your Discord
  • Consultation
  • Open Source
  • Become an Affiliate
Product
  • Documentation
  • Blog
  • Changelog
  • UI Blocks
  • Figma UI Kit
  • AI SaaS Starters
License
  • Activate License
  • Upgrade License
  • Invite Member
Legal
  • Terms of License
  • Global Configuration
    • Environment Variables
    • Feature Flags
  • Server Actions
    • Sending CSRF Token to Actions
    • Server Actions Error Handling
  • The Makerkit SDK
    • User SDK
    • Organization SDK
    • Organization Subscription SDK
    • Data Loader SDK
  • Architecture and Folder Structure
    • Structure your Application
    • Data Model
    • Overview
    • User Permissions
    • Subscription Permissions
    • RLS Policies
    • Custom React Hooks
This documentation is for a legacy version of Next.js and Supabase. For the latest version, please visit the Next.js and Supabase V2 documentation

Managing User Permissions in Next.js Supabase

Learn how to write a simple permissions system based on the users' role in your Makerkit applications using Next.js Supabase

Most permissions are written in a single file at src/lib/organizations/permissions.ts.

Here, you can find some of the examples used in the boilerplate so that you can start writing your own.

Why are permissions written in a single file? Because it's easy to write inline logic and lose track of it. Therefore, we will write all the business logic within the same file and encapsulated as simple functions.

Let's take a look at a simple permission function in the boilerplate:

src/lib/organizations/permissions.ts
/**
*
* @param currentUserRole The current logged-in user
* @param targetUser The role of the target of the action
* @description Checks if a user can perform actions (such as update a role) of another user
* @name canUpdateUser
*/
export function canUpdateUser(
currentUserRole: MembershipRole,
targetUser: MembershipRole
) {
return currentUserRole > targetUser;
}

The function takes two parameters: the current user's role and the target user's role, and checks if the current user can update the target user's role (or anything).

Now, we can use the function above with the IfHasPermissions component to display or hide some parts of the application. This component automatically injects the current user's role, such as below:

tsx
<IfHasPermissions
condition={(currentUserRole) =>
canInviteUser(currentUserRole, targetUserRole)
}
>
<InviteUserComponent />
</IfHasPermissions>

The InviteUserComponent component will be displayed if the condition is truthy.

Otherwise, you can use these functions throughout the application on both the client and the server.