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
We now have (and use) roles for authorization of certain API features. Consequently, the front end needs to gate certain functionality based on those roles. What's the best way to read them? What's a good convention for doing role-based checks? Do we have a bunch of feature checks like canSeeAllProposals() that route back to a centralize role check? Or do we just do role checks inline like isAdmin()?
I'll note that I can read our roles with the following code, but only if I disable a bunch of ESLint warnings (as shown). Hoping someone can help me sort this out:
@slifty I'd appreciate your eyes on the ESLint / TypeScript warnings specifically (i.e. the right way to read the roles), but also your architectural thoughts on how to apply the roles to front-end feature gatekeeping.
The text was updated successfully, but these errors were encountered:
We now have (and use) roles for authorization of certain API features. Consequently, the front end needs to gate certain functionality based on those roles. What's the best way to read them? What's a good convention for doing role-based checks? Do we have a bunch of feature checks like
canSeeAllProposals()
that route back to a centralize role check? Or do we just do role checks inline likeisAdmin()
?I'll note that I can read our roles with the following code, but only if I disable a bunch of ESLint warnings (as shown). Hoping someone can help me sort this out:
@slifty I'd appreciate your eyes on the ESLint / TypeScript warnings specifically (i.e. the right way to read the roles), but also your architectural thoughts on how to apply the roles to front-end feature gatekeeping.
The text was updated successfully, but these errors were encountered: