You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I would like to have a per field authorization on inputs, so users with the specific role can update some fields, and other users with different role can't.
Describe the solution you'd like
The ideal solution would be to have a possibility to mark certain fields in Input Type to require the authorization.
If the user has a role 'ADMIN' and he tries to fire update mutation using UpdateUserInput, specifing email field
then the authorization should pass an access to this update mutation.
If the user has a role 'CUSTOMER' and he tries to fire update mutation using UpdateUserInput, specifing email field
then the authorization should block the user from performing this operation.
Describe alternatives you've considered
I considered creating different mutation resolvers for different roles.
The disadvantages of this approach are:
significant amount of duplicated code
it's hard to automize it with crud generators
it looks like mixing methods to do one thing, since@Authorized decorator is available for fields in Object Types
Please let me know what you think.
The text was updated successfully, but these errors were encountered:
Have you seen graphql-auth-directive (NOTE: I'm the author)?
It's exactly what you want (see type-graphql integration) 🥳
It's missing the integration with input types but we can work together to implement it 🤞👍
Is your feature request related to a problem? Please describe.
I would like to have a per field authorization on inputs, so users with the specific role can update some fields, and other users with different role can't.
Describe the solution you'd like
The ideal solution would be to have a possibility to mark certain fields in Input Type to require the authorization.
If the user has a role
'ADMIN'
and he tries to fire update mutation usingUpdateUserInput
, specifingemail
fieldthen the authorization should pass an access to this update mutation.
If the user has a role
'CUSTOMER'
and he tries to fire update mutation usingUpdateUserInput
, specifingemail
fieldthen the authorization should block the user from performing this operation.
Describe alternatives you've considered
I considered creating different mutation resolvers for different roles.
The disadvantages of this approach are:
@Authorized
decorator is available for fields in Object TypesPlease let me know what you think.
The text was updated successfully, but these errors were encountered: