Is the authenticate hook needed before authorize?

[lukashass]

I'm currently working on a feature were partial data should be available to unauthenticated users.

It seems the main purpose of the authenticate hook is to add the ability to the context before calling authorize. Is that correct?

Would it be save to leave the authenticate hook and instead manually create the ability from context.params.user before calling authorize?

@fratzinger Can you help?

[fratzinger]

Moin!

Thanks for starting a discussion about that.

I don't see a problem with using context.params.user. Using authenticate has some advantages. Primarily I use it in one application where this use case perfectly fits into the authenticate mechanism. This is how I use feathers-casl:

• permissions rarely change per user/session. Only on logout/login.
• I need the permissions on the client for UX stuff

This results in two important things in our application:

1. So by using authenticate I only fetch the permissions once for the session; I would have to fetch the permissions on every request. But remember‼️ This only applies to websocket connections. For rest connections, you have to take the context.params.user route!
2. Using authenticate also has the great advantage that you can send the permissions to the client.

If you don't need the two points above, you're good to go with using context.params.user. But I think of two workarounds so also get the benefit of both points but can make it more flexible:

1. You can add a ability to a connection (for example in the channels.ts file). While I did not have try it, it should work that that also gets populated to context.params.ability.
2. If the client needs the permissions, then you also can create a service for finging all relevant permissions.

Hope this helps. Cheers 🍻