Hi Cerbos - another question say I have a backend...
# help
Hi Cerbos - another question say I have a backend endpoint w/ some path /base_path/list_all_widgets Normally GETting on this would returns all widgets - some of those are type A, B, C.. etc now I have derivedRoles, say A-Read, B-Read, . .etc. given that most example I see have the cerbos.isAllowed(..) call take place before hitting the resource in question - how should I approach this case? • Is it even correct to think of /base_path/list_all_widgets as a single resource? ◦ should I create some new paths: /base_path/list_widgets/arg=widget_type and /base_path/list_allowed_widget_types? • Is there a good example of how to handle this kind of case? •
maybe replace application logic with a cerbos call that asks ~ what actions like ‘GETwidget type*’ are allowed
If I understand you correctly, you want to filter out the widgets that the user does not have access to? Cerbos has a PlanResources API to help you filter out the items from your data store. Essentially, tell Cerbos who the principal is and which resource kind they are trying to access and it'll return you a tree of conditions that must be met by each resource instance.
thanks Charith, looking at the docs - it makes sense - but how do write a unittest yaml that captures calls to
as opposed to
i mean - i can write a unittest using requests and API call - but I like the pattern I see for /api/check/resources - where I can just write a .yaml
Unit tests for
should be in your own code because that's where bulk of the work is and where mistakes are most likely to happen. You need to make sure that your code can correctly process the response and produce a query for the data store you're using. That's why the Cerbos test framework doesn't have a way to write tests for it.
ok thats fair - thank you
that being said - /api/check/resources can still full test that specific resources are/are not accessible . . so may this is better (no need to support 2 ways to check the same information)