Edit: This setup is entirely client-side within the Plasmic Studio environment. This means it might be accessible directly in the browser if Plasmic’s API integration and direct database connections aren’t handled on the backend. I’m certain their integration settings (like URLs and API keys) are secured, but I’m unsure about how the data responses themselves are handled. Regardless, this method essentially mirrors the Supabase client-side SDK, which also utilizes local storage and operates client-side.
In any case, this approach lets you quickly prototype and test your idea before committing to a fully server-side architecture if you ultimately decide to use cookies for authentication.
@abel_conde The easiest method I’ve found for integrating Supabase with Plasmic, without resorting to custom code components, custom authentication implementations, or importing external projects, is to use Plasmic’s built-in API integration directly. This approach even allows you to leverage Supabase’s Row-Level Security (RLS), making it ideal for multi-tenant applications.
Here’s how it works:
- Create a signup form: Use Plasmic’s form components to create a form with “email” and “password” input fields and a submit button.
- Implement signup logic: On form submission, use Plasmic’s HTTP integration to make a POST request to your Supabase project’s signup endpoint:
[your supabase project base url]/auth/v1/signup.
- Create a login form: Similarly, create a login form with “email” and “password” inputs and a submit button.
- Implement login logic: On login form submission, use Plasmic’s HTTP integration to make a POST request to your Supabase project’s token endpoint:
[your supabase project base url]/auth/v1/token?grant_type=password.
- Store essential data in local storage: Store the returned access token and user ID in local storage. Do not store the refresh token in local storage.
- Use the access token for authenticated requests: For all subsequent HTTP requests to your Supabase tables that require user authorization, include the access token in the
Authorization header using the Bearer [dynamic value of the access token from local storage] format. This ensures that RLS is enforced and all JWT claims are correctly processed by Supabase.
- Refresh tokens securely: Use Plasmic’s Supabase direct connection to refresh tokens. Query the
auth.refresh_tokens table in Supabase, filtering by the stored user_id and revoked = false (or whatever your “not revoked” status is). This method avoids storing the refresh token in local storage, which is a significant security improvement.
Note: Use the Plasmic Supabase direct connection for tasks unrelated to user authentication or authorization (JWT). This is useful for things like complex database queries involving joins, administrative tasks that don’t need RLS enforcement, and situations where you want to bypass RLS entirely. (For example, we used it to retrieve a user’s refresh token via their session ID, avoiding the need to store the refresh token directly in client-side storage—which is even more secure than how the standard Supabase client SDK handles it.) Think of this direct connection as your Supabase “service role” key – it has full access. For all user-facing interactions that do require user context and RLS enforcement, you should use the Supabase “anon” (anonymous) key.
Remember to think of the JavaScript API library (like the Supabase client-side library) as simply a wrapper around standard API calls. This means that all the underlying API requests will function the same way, regardless of whether you use the library or make the calls directly. Therefore, you can use Plasmic’s built-in REST or GraphQL API functionality to make all your API calls directly, bypassing the need for the full client-side library in many cases.
[Edit] Remember to remove the stored access token from local storage when logging out. You can do this by making a request to your Supabase project’s logout endpoint ([your supabase project base url]/auth/v1/logout) with the appropriate authorization header (Authorization: Bearer [dynamic access token]). Immediately following this request, use a “Run Code” interaction in Plasmic to remove the token from local storage (e.g., localStorage.removeItem("[your key name]")). Finally, add a navigation interaction to redirect the user to your login page.
This setup gives you a complete signup, sign-in, and logout system. (You can easily add features like password resets and email changes later using the same principles.)
I haven’t enabled Plasmic’s built-in authentication, nor am I using any custom authentication methods or custom code components. Everything is done within Plasmic’s no-code environment, with the exception of using the “set” and “remove” Run Code interactions for local storage management. I do, however, have Supabase Row-Level Security (RLS) fully implemented and working.
.