Is it possible to create custom user roles with the current wasp auth? Such as non-admin staff
is it possible to create custom user roles without circumventing wasp auth?
For example, would it be possible to create staff accounts that aren't admin but can view pages that noraml users can't?
Am I overcomplicating this?
14 Replies
Hi @fred-123. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Yes, you can create custom user roles with Wasp's current auth system, but Wasp doesn't have built-in role-based access control (RBAC) yet. You'll need to implement this yourself.
The simplest approach is to add a
role
field to your User
entity and then check this value in your queries/actions to determine access permissions:
For more complex scenarios, you could create separate entities for roles and groups:
1. For fixed roles: Add a role
field to the User
entity and check its value
2. For dynamic user groups: Create a UserGroup
entity with an N-to-N relationship with User
This is standard app/database design and not specific to Wasp. As mentioned by a Wasp team member in Discord: "this is completely left to you at the moment. We do have plans to add a default support for it in Wasp, something like RBAC (role based access control), but that will be in the future versions of Wasp, not super soon." Discord support thread
If you need a working example, you can check out the open-saas template which already implements admin roles and an admin dashboard: <https://opensaas.sh/
You're not overcomplicating this - role-based access is a common requirement in many applications!
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @fred-123, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?Makes sense. Just thought there might be a wasp way of doing it since its somewhat related to auth.
Not at the moment, but we're thinking of implementing Multi-tenant and Role Based Auth in the future. Is that what youre looking for?
That's what I'm looking for 😄
+1 :boi: from me to support this future plan
I'm brooding over having to figure this out but would love to have "team" admins for my users & role based access within teams.
Hi All, are there any updates on this being done. I'm seeing so many threads requesting similar features? If not I'm super reluctant to be adding a separate db query for every page just to get organisation data for a user. Are we not simply able to change the context.user to join our "organisation" entity so we have all the information here. Basically I want an organisation to hold the subscription details not the user. And only certain actions or pages can be performed based on your subscription. Also you can only load data that is linked to your organisation.
I’ve decided not to move forward with multi tenant for my initial product release, but when I was deciding on this for my MVP I saw it as something like changing the current user model to be an organization model & adding entities to the organization model for users / user access types.
(Assuming that the existing wasp auth still takes care of organizational data access control safely) I imagined using some Middleware config/maybe an app wrapper to manage user access & permissions client/server side.
Was too much for me to reverse engineer & I’m not experienced enough to feel confident that I didn’t just write out a bunch of hack nonsense there.. but if you do figure it out & have the time to share your high level architecture id love to hear it!
(P.S if dabois are reading this, still a major +1 :be: vote from me for Multi tenant to be part of the OpenSaaS roadmap.)
P.P.S it would also bee pretty sweet (hah get it, bee?) as part of MT implementation if Admins were be able to “mimic” or “view as” X user/X user role for QA & bug fixes
Thanks G35x, yeah I'm very surprised this hasn't been add yet, the queries go back as far as 2022, and for property business/enterprise SaaS apps, they pretty won't work without some-level of multiple user, multi-tenant.
In terms of restricting data I can do this pretty easily, just using queries, views, filters etc, but the crux is getting access within context.user or context.Org so that you don't have to do a db query everytime a page loads or a query/action is required, I might try and hack and see if breaks anything then post back here for advice on security. I like you am not a pro dev, so worry I'll miss something major 🙂
We are currently building out our 1.0 dev roadmap, and making auth better and more modular is on there (including the UI).
The details will be released when we work it out a bit more. We definitely want to provide top-tier auth experience. :wizardboi:
Hey all, I've added this thread to the relevant issue to help prioritize it for 1.0: https://github.com/wasp-lang/wasp/issues/491
Thanks for reporting!
The main answer is just "prioritization" -> we are are working on a lot of things, many of them at the core of the Wasp, so not everything gets to get done as fast as we want, even if we are aware of it and track it. This is one of those issues -> we plan to do it at some point for sure, but since it is doable (even if not ideal experience) on your own, with the queries as you said (instead of data already being available in context.user), it didn't get prioritized so far due to other more crucial areas of Wasp where we want to make progress.
What Filip says is correct though, for 1.0 which we are building towards now, we will be improving Auth quite a bit, so we will also be considering this for sure, and will release Roadmap quite soon.
Btw one thing that is a bit tricky with this is that we don't want to assume, in Wasp, how a user wants to structure the whole thing with Orgs and similar. Many apps do it the same/similar way indeed, but it is business logic, and if we pick one way of supporting it in Wasp, it won't suite everybody. What we will likely be looking to do is support it more on the userland level, we have yet to see what is the best solution. What we might do though, is allow customizing the "internal" query used by Wasp to obtain the context.user in actions -> that is what you are looking for if I got it right.
I just created more specific issue for it here also https://github.com/wasp-lang/wasp/issues/2819
GitHub
Allow customizing how context.user (in Operations) is obtained/popu...
Imagine you can customize how that user is obtained, so that for example it is always populated with the organisation info. Maybe the solution is to provide direct mechanism for customizing this, o...
Completely understand this and having worked at the prioritisation level on large enterprise level products I totally get this so don't worry, just excited that it's being thought about and that it's in the backlog, who knows what the future Olds, things change all the time 😃
Hah ok, I am sure you do then 😄 ! And you are very right about the future. People often assume we don't care about some unresolved issue, but we are often very aware and crying inside hah, just can't get to it due to so many other things.
I think the roadmap we are working on now will help quite a bit, because we will make it public so it will give people a better feeling what are we working on and what are the priorities.
lol