Adds a hasRole() and isAuthenticated() to determine the role membership or if the request is authenticated

[dthyresson]

Currently we have hasRole method on the web side of things, but it would be neat having it on the api side. We currently have requireAuth, but that will throw an error while hasRole would most likely return a boolean.

For now it's super easy to just add copy the requireAuth logic and change out the throwing of exceptions to boolean, but would be nice seeing a native way in future RedwoodJS versions.

Fixes #1730

Adds a hasRole() and isAuthenticated() in auth.js that return booleans rather than exceptions (as is done by requireAuth) so these checks can be used to determine the role membership or if the request is authenticated.

Also:

• Uses roles instead of role to be clear than can check a set of values Fixes TS error in default auth.ts #3024
• Moves the parseJWT util of api and into api/auth where it really belongs

NOTE: Draft tested in local RBAC blog identity app.

Also needs to update dbAuth.auth.js.template (Done!)

[jtoar]

@dthyresson do you think the RFC here is part of the future for addressing the disparity? #2431

[dthyresson]

@dthyresson do you think the RFC here is part of the future for addressing the disparity? #2431

I don't think this addresses #2431 since as I read the issue, that is more of a web-side concern to check membership/permissions -- and that can depend highly on the auth provider and the implementation.

This PR simply intends to make checking server-side if the user belongs to a role (or not) rather than throwing exceptions when checking.

It helps if you just "need to know if they do" without having to do some try/catch instead.

I have a feeling that dbAuth might be a good first case for having both roles and permissions implemented --and then can think of a way web-side to enforce.

[dthyresson]

Will need doc change to use roles instead of role and also update RBAC cookbook.

[dthyresson]

From @Tobbe

I can't make up my mind about this one

The code clearly handles that you don't pass a role in. But on the other hand it feels too weird to call hasRole(). From just looking at that, without reading the implementation, it's not very easy to know what it would do. Would it check if the user has any role? Any role at all? Or would it check if the user has the role undefined?

I see. The questions are what if the developer either set roles to

• undefined
• empty array

In both cases, the function should return false.

But, then does the question, does the user have undefined roles mean they have no roles assigned, ie unassigned roles -- and then really need to check if their role assignment is undefined or roles length is 0.

Or, should undefined throw an Error?

Or, is undefined simply invalid and return false because preventing access is better than granted access.

Perhaps just a comment to clarify?

[Tobbe]

From a theoretical/academical point of view I think it should be a compilation error in a TS project, and a runtime error in a JS project.

But from a DX pov it's probably nicer to do what you've done and just return false. So a comment is probably the best solution.

[dthyresson]

Added comment in JSDoc if not roles