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?1 Reply
Just an idea, store some kind of flag in context, you can then filter out most of the calls that don't need to verify the users permissions.
Also you'll have access to the url/route, use regex with a capture group to capture Facility B, foo, bar, blah etc. to use in your permission logic.
If you're worried about performance, you could store the permission set in a cache, either in memory or redis. This would be quicker than hitting a db with every verify flag in context.