vapor
Advanced Permissioning In Middleware
I need to handle somewhat complicated permissioning logic, for example:
The
User A can read (but not write) tasks from Facility B
Is there a good pattern for applying this sort of logic in middlewares? Currently, I can create a verbose permission set in Context
for that user, but I'm not sure how best to handle a facility-specific route, for example trying to read tasks from Facility B
.The
Context
will contain all of that user's permissions, but I'm not sure how to check those permissions against a route-specific ID (for example facilityID
) in a middleware.
I don't think I'd want to set that facilityID
in context (since a lot of procedures won't have a facilityID
at all) and it doesn't look like there's a way to pass dynamic values into middleware using Meta
.
Any thoughts?5 replies
Middleware-ish for client
Hi! I had a quick question about client-side usage:
I have users with long-running sessions, and if they tokens expire the backend returns a 401. In the old codebase I'm migrating from there was a check force a token refresh if certain parameters were met, such as status === 401, route is one of x, etc. Is there a way to handle that on the @trpc/client ? something just like: for any requests, if returned status is 401, and route is one of x, force a token refresh? Thanks!
5 replies