camunda / camunda/api-test-generator
RBAC read-deny: search/list endpoints via row-level filtering (200 + empty items, not 403)
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 3
- Avg merge
- 13h 41m
- Merged PRs (30d)
- 23
Description
Follow-up to the read-side RBAC deny-test vertical slice (#359). Get-by-key reads return 403 when the caller lacks the permission, but search/list endpoints behave differently: Camunda applies row-level filtering — a scoped user gets 200 with an empty items list, not a 403 (see search-authorization-api.spec.ts in the OC e2e suite, cited in #359).
Scope: a distinct assertion shape for */search (and list) read endpoints — as a zero-grant / scoped user, expect 200 + items: [] (or filtered subset), rather than a deny status. Likely a separate scenario kind (e.g. auth-filter) and emitter assertion.
Why separate: it's a different oracle from the 403 deny used for get-by-key, so it doesn't fit the auth-deny path cleanly.
Relates to #359.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the search-authorization-api.spec.ts example cited in #359, then trace the existing auth-deny scenario and emitter in the generator. Done means search/list read endpoints use a distinct filtering assertion and verify 200 with an empty items list or filtered subset for a zero-grant or scoped user.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, authorization, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 62/100