• If I use custom authorization (in my case, use supabase auth / row-level security), do I still need to create a plasmic user? The API docs for the PlasmicRootProvider don’t show the user or userAuthToken props, but I see them here: https://github.com/plasmicapp/plasmic/blob/master/examples/supabase-auth-nextjs-pages-codegen/pages/ssr.tsx#L34C45-L34C58
• My issue with creating a plasmic user and mapping to a simple “role” is that users can be in multiple teams and have different permissions in each team. I see that I can use Role in “Page Data” and then dynamic values for component visibility, is that the best practice in that case?
• In general… I am thinking I just want bypass the plasmic auth, but I want to make sure I am not missing anything really critical there?
Hi Addison
• You don’t need to create a plasmic user to use custom auth, the set of permissions that you define in the permissions tab are independent of plasmic auth a bit more about it is explained in https://docs.plasmic.app/learn/auth/#permissions. The PlasmicRootProvider still requires the user / userAuthToken so that plasmic is able to handle the visibility of pages or parts of the page based on the current user, also handling data source operations that you chose to protect within plasmic.
• Yes in case you want to block a page or hide a page section based on the role level that is the expected best practice
Hi Addison, no worries about bringing it up, feel free to ask in any doubt
You still need to call createPlasmicAppUser as it provides a valid value of user to that is equivalent to your studio currentUser , I meant in the sense that you don’t need that the the user created by createPlasmicAppUser being a plasmic user with access to your app through studio. It can be any user as long as it has valid permissions in the app auth settings.
one more quick question @fmota, the supabase example (I think written by you ) mentions something in plasmic-auth.ts
sing supabase session as a source of thruth for the user’s email.
// This could have better performance by managing plasmic user and supabase user
// separately, but this is a simple example.
You can improve the performance by separately saving the plasmic user in a session, in the current example, every time getPlasmicAuthData is called it’s calling createPlasmicAppUser , but if you have it saved by the session you wouldn’t need to call it every time
so… one more thing, it seems like in many cases, I am doing this primarily to get the currentUser object setup so that plasmic can do it’s thing in the studio… but my “real” session is also more complex as I have some tokens/creds associated that are fetched on login
So, I can’t really just use currentUser so generally I am not and instead have created my own dataProvider with my session.
I think this will work fine in real app, but I think might cause issues in studio where I haven’t gotten a “real” session… so I do still need to figure out how to do some interactive in studio to populate my real session… is there any hooks I have in studio?
what I mean is that I have other custom code components that rely on my user session. To populate that session I need to login to my custom auth. I am not sure how to force that to happen from studio
I use a custom react context, I don’t want some of these values to be exposed to studio users
So the issue I am figuring out is if the studio user needs to do an interactive login (social login) within studio to populate the react context, will studio be okay with that?
(err and reading back previous comment, I have two “views” of my session, one I load via data provider after social login that has fields that can be used dynamically, and another that is a react context only for use by components which has more fields which cannot be used)
It’s hard to say, it depends on how the interactive login is going to work out, you should be able to interact with your component in studio with interactive mode and their internal states should be kept while you use them, but if your login requires redirects it won’t work out from studio, as it won’t be able to go back to the artboard, even if it doesn’t require redirects it may have some caveat to it.
yes, redirects are in play as it is mostly oauth2. Which I could possible just see having my users do the login through the target, but it seems studio sandboxes all the state and it doesn’t share any context
