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
{{ message }}
This repository has been archived by the owner on Dec 16, 2024. It is now read-only.
The new useAuth abandoned the idea of allowing additional user meta data to be consumed via a "whitelist" prop on ProvideAuth context. This code should be removed and / or devise an alternative method for auth middlewares to pass special snowflake permission type data.
Example scenario: User has a permission to see a grid of items. That grid has an action column to "Edit". User may only have permission to edit items x,y, and z based on some other group/org based assignment. UI would need some way to decipher if an edit button would be rendered for a given item row.
The text was updated successfully, but these errors were encountered:
Instead of a whitelist could we just give access to all the claims on the id token? Alternatively we can create a change on the permission filter component to dictate a function to determine permission over always grabbing from the access control list.
The new useAuth abandoned the idea of allowing additional user meta data to be consumed via a "whitelist" prop on ProvideAuth context. This code should be removed and / or devise an alternative method for auth middlewares to pass special snowflake permission type data.
Example scenario: User has a permission to see a grid of items. That grid has an action column to "Edit". User may only have permission to edit items x,y, and z based on some other group/org based assignment. UI would need some way to decipher if an edit button would be rendered for a given item row.
The text was updated successfully, but these errors were encountered: