Skip to Content

@rbac directive

Published: November 23, 2021

The @rbac directive attaches rules for Role Based Access Control (RBAC) to Operations. Before you're ready to define RBAC rules to Operations, make sure you have defined the roles already.

Roles are simply strings, like "admin" or "user", that can be attached to a user. Then, based on the roles of the user and the rules you've defined, WunderGraph determines if a user is allowed to execute an Operation.

Find below an annotated Operation showcasing all available options to use the @rbac directive.

mutation ($email: String!)
@rbac(
# the user must have all listed roles, "superadmin" and "user"
requireMatchAll: [superadmin,user]
# the user must have the role "superadmin"
requireMatchAll: [superadmin]
# the user must have one of the roles of "user" or "admin"
requireMatchAny: [user,admin]
# the user must not have the role "user"
denyMatchAll: [user]
# the user must not have the roles "user" and "admin"
# it's ok if the user has either the role "user" or the role "admin"
denyMatchAll: [user,admin]
# the user must not have the role "user"
denyMatchAny: [user]
# the user must not have the role "user" or the role "admin"
denyMatchAny: [user,admin]
)
{
deleteManymessages(where: {users: {is: {email: {equals: $email}}}}){
count
}
}

A common use case is that you want to grant access to an operation explicitly to a single role. In this case, you'd use the requireMatchAll rule like below:

mutation ($email: String!) @rbac(requireMatchAll: [superadmin]){
deleteManymessages(where: {users: {is: {email: {equals: $email}}}}){
count
}
}

By attaching role based access rules to operations, we're almost done. What's missing is to actually grant our users certain roles. For that, we've got to implement a hook, which is described in the hooks section on authentication.


Product

Comparisons

Subscribe to our newsletter!

Stay informed when great things happen! Get the latest news about APIs, GraphQL and more straight into your mailbox.

© 2021 WunderGraph