Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow space application supporter to access specific droplet endpoints. #2220

Closed
monamohebbi opened this issue Apr 21, 2021 · 1 comment · Fixed by #2334
Closed

Allow space application supporter to access specific droplet endpoints. #2220

monamohebbi opened this issue Apr 21, 2021 · 1 comment · Fixed by #2334
Assignees
Labels
space-application-supporter https://github.com/cloudfoundry/cfar-proposals/issues/22

Comments

@monamohebbi
Copy link
Contributor

monamohebbi commented Apr 21, 2021

Issue

Allow space application supporter to access specific droplet endpoints.

Context

We are introducing a new role and we want to make sure it has the right access.

Expected result

A space application support should be able access the following endpoints:

GET /v3/droplets/:guid
GET /v3/droplets
GET /v3/packages/:guid/droplets
GET /v3/apps/:guid/droplets

Acceptance

A space application supporter would see the same info as a space developer assigned to the same space for these and only these droplet endpoints.

Documentation

When I browse to any of these endpoints on v3 docs I can see the Space Application Supporter role in the list of permitted roles with an indication that this role is not fully implemented and the permissions will be changing.

@monamohebbi monamohebbi added the space-application-supporter https://github.com/cloudfoundry/cfar-proposals/issues/22 label Apr 21, 2021
@monamohebbi monamohebbi added this to To do in Space Supporter via automation Apr 21, 2021
@monamohebbi monamohebbi changed the title Allow space application supporter to access specific build endpoints. Allow space application supporter to access specific droplet endpoints. Apr 21, 2021
@ctlong ctlong self-assigned this Jun 9, 2021
@ctlong ctlong moved this from To do to In progress in Space Supporter Jun 9, 2021
@ctlong
Copy link
Member

ctlong commented Jun 9, 2021

@monamohebbi @sweinstein22 Should GET /v3/droplets/:guid for Space Application Supporters be redacted in a similar way to the org and space managers, and all auditors? Only admin roles and Space Developers are able to access the non-redacted list at present.

Acceptance says that this new role should see what a Space Developer sees, but this felt like a potential exception, so I wanted to confirm.

Specifically, this redaction replaces the contents of the execution_metadata and process_types keys with messages like [PRIVATE DATA HIDDEN].

monamohebbi pushed a commit that referenced this issue Jun 10, 2021
* Decided to have some fields in v3/droplets/:guid be redacted (in a
similar fashion to every role except admin roles and space developers)
* Updated documentation
* Refactored some of the droplets request specs to use it_behaves_like

[#2220]

Co-authored-by: Weyman Fung <weymanf@vmware.com>
Co-authored-by: Carson Long <lcarson@vmware.com>
weymanf added a commit that referenced this issue Jun 11, 2021
* Decided to have some fields in v3/droplets/:guid be redacted (in a
similar fashion to every role except admin roles and space developers)
* Updated documentation
* Refactored some of the droplets request specs to use it_behaves_like

[#2220]

Co-authored-by: Weyman Fung <weymanf@vmware.com>
Co-authored-by: Carson Long <lcarson@vmware.com>
weymanf added a commit that referenced this issue Jun 11, 2021
* Decided to have some fields in v3/droplets/:guid be redacted (in a
similar fashion to every role except admin roles and space developers)
* Updated documentation
* Refactored some of the droplets request specs to use it_behaves_like

[#2220]

Co-authored-by: Weyman Fung <weymanf@vmware.com>
Co-authored-by: Carson Long <lcarson@vmware.com>
@monamohebbi monamohebbi moved this from In progress to Acceptance in Space Supporter Jun 15, 2021
Space Supporter automation moved this from Acceptance to Done Jun 16, 2021
mkocher pushed a commit that referenced this issue Jun 22, 2021
* Decided to have some fields in v3/droplets/:guid be redacted (in a
similar fashion to every role except admin roles and space developers)
* Updated documentation
* Refactored some of the droplets request specs to use it_behaves_like

[#2220]

Co-authored-by: Weyman Fung <weymanf@vmware.com>
Co-authored-by: Carson Long <lcarson@vmware.com>
bepotts pushed a commit that referenced this issue Jul 13, 2021
* Decided to have some fields in v3/droplets/:guid be redacted (in a
similar fashion to every role except admin roles and space developers)
* Updated documentation
* Refactored some of the droplets request specs to use it_behaves_like

[#2220]

Co-authored-by: Weyman Fung <weymanf@vmware.com>
Co-authored-by: Carson Long <lcarson@vmware.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
space-application-supporter https://github.com/cloudfoundry/cfar-proposals/issues/22
Projects
3 participants