If I use supabase auth as a custom auth provider, I assume plasmic still connects to the db via a direct connection string and therefore still does not work with row level security as per this part of the docs:
https://docs.plasmic.app/learn/supabase/#plasmic-and-rls
Correct?
That’s correct.
thinking through this; if someone makes an app, we’ll call it BestAppEver, that uses Supabase as its Backend as a Service and Plasmic as its Front End Builder and uses Plasmic for Custom Auth; then the users of BestAppEver get the characteristics of what Row Level Security Provides via how the BestAppEver is created through Plasmic with the features of Plasmic that is shown in the following videos
• Custom user properties in Plasmic
• Creating new user setup flows in Plasmic
So, I feel like the creators of Apps through Plasmic don’t have as much to be concerned about if they turn off Row Level Security on Supabase if the only connections to Supabase are coming from Plasmic; but if they have other connections going into Supabase from a different app that don’t take over the functions of RLS within that App itself, then they run the risk of exposing row level information that should be protected
Yes that is correct. Just take care to protect sensitive database operations with Plasmic auth features!
I’d be curious if the video that @yang did with the Twitter Clone could touch upon the Row Level Security a little more in depth. I’ve been thinking about it more; and I’m curious if a good happy place would be for the join tables to be what gets used by Plasmic so only a fraction of the data stored in Supabase has to deprecate the security features and that way the developer can create specific audit policies for that single table and the original tables can have the built in security features of Supabase. I know one of the selling points of using Supabase is the ease to create AI enabled applications through the other integrations; so it’d be nice to find a way that developing using Supabase and Plasmic didn’t mean that was the only integration that you can have with Supabase.
I’m building an app in Plasmic with a Supabase backend and my plan is to totally avoid using the supabase integration that Plasmic provides since it basically gets rid of most of the benefits of Supabase, especially RLS.
Instead, I’ll be using code components to run data fetching & mutation to/from Supabase (via data fetching code components)
This means I can use the normal supabase-js library and interact with supabase via the auto-generated API rather than direct connection.
I’m still working out the details of how to efficiently implement this (most notably, how I can authenticate users)
However, I’ve had partial success so far: I have written a data providing component for one of my supabase tables inspired by the data fetching code component example on the page linked above.
My example provider is attached
I then register that component in plasmic-init.ts using the code below.
Then in Plasmic Studio I can add the StaffProvider component to a page. This exposes a state variable called Staff with data fetched from supabase.
After adding the StaffProvider component to a page, I also get element actions available within that page that I can use to create, edit and delete staff. These can hooked up to forms or buttons in Plasmic to update data in supabase.
So far, my solution is working using the plasmic loader, and I haven’t needed to start using codegen.
If anyone wants to collaborate on getting this approach working, please let me know.
PLASMIC.registerComponent(StaffProvider, {
name: 'StaffProvider',
providesData: true,
props: {
children: 'slot'
},
refActions: {
deleteStaff: {
description: 'delete a staff member',
argTypes: [
{name: 'Staff ID', type: 'number'}
]
},
addStaff: {
description: 'add a staff member',
argTypes: [
{name: 'staff', type: 'object'}
]
},
editStaff: {
description: 'edit a staff member',
argTypes: [
{name: 'staff', type: 'object'}
]
}
}
})
Using code components and exposing element actions is a great way to leverage Supabase RLS features. Let me know if you run into any issues.
Thanks @jason I am actually a bit stuck on how to create auth functionality for my use-case.
I’d like to define & run user login/logout actions & also an action to get details of the current user directly in the nextjs app code that hosts the plasmic code components, rather than using plasmic auth or a custom auth provider (because I’m already running the supabase CRUD operations in the code & don’t need the extra complexity of adding & managing users in plasmic on top of supabase).
I’m going to add middleware to my nextjs app to define which routes are login protected or not too (rather than using plasmic to do this), and the native supabase auth features will take care of authenticating API calls to supabase too.
But I do need to pass details of the currently logged in user (email, role etc) into Plasmic so I can use it to build the UX in Plasmic Studio (eg show/hide buttons, display logged in user details). And I also need to be able to create some forms in plasmic that call the code-defined login/logout logic.
How can I expose login/logout methods & also data about the logged in user for use in plasmic studio, without enabling plasmic auth?
Would it be just another data provider component with element actions? Perhaps added to the page layout so every page gets access?
Or is there a better way to pass global state & actions to every page in plasmic?
ya, I’ve done experimented w/ codegen and code components and avoided the Plasmic Auth; but the benefits of developing with the Plasmic Auth once I also experimented with that was a huge efficiency in speed of what I was developing. The ability to view the application as a certain user and to leverage the Boundary Loading components and whatnot were extremely useful
ya, and this is helpful info
@alyssa_feola thanks for your thoughts on Plasmic Auth!
@definitive_ermine Correct, you can use a DataProvider component. You can expose login/logout actions in the DataProvider and/or element actions. This would not require Plasmic Auth.
You can also consider using a GlobalContext, then setting the props of the context wherever you instantiate your PlasmicRootProvider/GlobalContextsProvider.
Thanks @jason I read and re-read the info on global contexts yesterday but couldn’t make it work because I wasn’t sure what the Component that you load as global context should look like. Do you have any examples? In the documentation page, I’d love to see what the ProductContext component itself looks like, for example.
@alyssa_feola thanks I’ll check out those posts, much appreciated
Sure! Here’s an example using registerGlobalContext: https://github.com/plasmicapp/plasmic/blob/master/examples/scroll-aware-navbar/plasmic-init.ts
@definitive_ermine have you checked out the supabase-demo example?
https://github.com/plasmicapp/plasmic/tree/master/examples/supabase-demo
Thanks to both of you! Lots of reading for me to do! Much appreciated
@definitive_ermine where did you get to with implementing Supabase auth without integrating with Plasmic Auth. I am currently working through the same thing as I will likely end up with a more complex role based access model not supported by Plasmic Auth. I have signup/login actions working currently using element actions to call the supabase library and data provider to make the results (e.g. current user) accessible in the Plasmic UI. Thinking of changing them to globalContext to give a little bit more flexibility but also, if it ain’t broke… Open to collaborating.
Hi Ryan, I would love to collaborate! I’m on holidays until 22nd Jan. Does it work if we talk after that?
I’ve got basic login and logout mostly working too, along with global settings for simulating a logged in user in the plasmic studio.