cloudfoundry / cloudfoundry/cloud_controller_ng

Restrict POST /v3/service_plans/:guid/visibility to only support appending orgs (and not changing visibility type)

Open
#4,606 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
207
Forks
373
Avg merge
2d 12h
Merged PRs (30d)
56

Description

Summary

The current implementation of POST /v3/service_plans/:guid/visibility is somewhat inconsistent with REST semantics and allows operations beyond simply appending organizations. Specifically, it can also change the visibility type (e.g., to public or admin), which overlaps with the semantics of PATCH /v3/service_plans/:guid/visibility.

Problem

From a REST perspective:

  • POST should be used to add new resources or associations (in this case, adding orgs to an existing visibility list).
  • PATCH should be used to modify existing state (e.g., changing the visibility type to public or admin).

Currently, POST behaves more like a PATCH, as it allows changing the visibility type, not just appending orgs. This blurs the intended semantics and increases the risk of accidental type changes when clients are only trying to add organizations.

Proposed Change

I propose tightening the semantics of POST /v3/service_plans/:guid/visibility:

  • Allow POST only when type = organization.
  • Ensure the target plan already has visibility type organization. If the plan’s visibility type is not organization, the request should fail with an appropriate error (e.g., 422 Unprocessable Entity).

This ensures that:

  • POST is used solely for appending organizations to organization-scoped plans.
  • PATCH remains the correct method for changing the visibility type.
Compatibility / Migration

This change could break existing clients that currently use POST to modify visibility type. However, those clients can simply switch to using PATCH, which already supports the same behavior. This aligns both endpoints with clearer REST semantics going forward.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the POST /v3/service_plans/:guid/visibility and PATCH /v3/service_plans/:guid/visibility entry points, comparing how each handles visibility types and organization associations. Done means POST accepts only organization visibility for plans already using that type, while PATCH remains responsible for changing the visibility type and invalid POST requests return an appropriate error.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
api
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.