Add filter to secret list for acl secrets
Bug #1459780 reported by
Douglas Mendizábal
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Barbican |
Fix Released
|
Wishlist
|
Elvin Tubillara |
Bug Description
Add a filter to secrets list to retrieve secrets which are accessible through the ACL.
Changed in barbican: | |
importance: | Undecided → Wishlist |
Changed in barbican: | |
assignee: | nobody → Elvin Tubillara (edtubill) |
Changed in barbican: | |
assignee: | Elvin Tubillara (edtubill) → nobody |
Changed in barbican: | |
assignee: | nobody → Elvin Tubillara (edtubill) |
Changed in barbican: | |
status: | New → In Progress |
Changed in barbican: | |
milestone: | none → liberty-rc1 |
status: | Fix Committed → Fix Released |
Changed in barbican: | |
milestone: | liberty-rc1 → 1.0.0 |
To post a comment you must log in.
CR(s) related to this bug should include the 'DocImpact:' and 'APIImpact:' flags, describing the API and documentation updates required.
The normal/existing GET /v1/secrets call returns a list of secret metadata for the same project-ID as the requesting client. It does NOT return the list of secret metadata that the requesting client is on the ACL for. This current behavior should NOT change per this bug.
Rather a modified GET request should be added, with the resulting GET call looking something like this:
GET /v1/secrets? acl-only= true&.. ..other filter parameters as needed...
So if acl-only=true is specified, then the query ONLY returns a paged list of secret metadata that the requesting client is on the ACL for. Hence the query will have to search secrets for ACL matches for the requesting client. Note that this search mode does NOT ALSO return the list of secret metadata for the requestor's project-ID. This should ease the query/paging process.
If acl-only=false, or is not specified, then the current project-ID-ONLY based GET should be used.