Bypassing PlasmicAuth for custom auth

I have a few questions about auth:

• 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:
• 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?

You shouldn’t need to create Plasmic users if you are using custom auth. @fmota can help you sort it out :slightly_smiling_face:

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 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

@fmota sorry, an old thread I am bringing backup, but a few more questions as this is now at the top of my stack again:

  1. when you say I don’t need to create a a plasmic user, do you mean I don’t need to call createPlasmicAppIUser as defined here?
  2. I am wondering if when using custom auth, does that count towards the user count in plasmic pricing?

Hi Addison, no worries about bringing it up, feel free to ask in any doubt

  1. 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.
  2. It doesn’t count

okay cool :+1:

one more quick question @fmota, the supabase example (I think written by you :slightly_smiling_face: ) 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.

I was trying to reason out that that would mean… but not positive?

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?

@fmota ^^

I am not sure if I fully understood your case, the DataProvider should allow you to access the data that is being provided in the 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

How are your code components reading the data from your session ? If it’s provided through the DataProvider they should still be able to read it or through a global context , but this won’t be updated by switching the user using the View as select

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

(session and cookie state I mean)