Skip to content

Add validation for credentials in SB update to be not blank#2939

Merged
philippthun merged 3 commits intocloudfoundry:mainfrom
sap-contributions:issue-2937-fix-broker-lock-on-missing-credentials
Sep 7, 2022
Merged

Add validation for credentials in SB update to be not blank#2939
philippthun merged 3 commits intocloudfoundry:mainfrom
sap-contributions:issue-2937-fix-broker-lock-on-missing-credentials

Conversation

@svkrieger
Copy link
Copy Markdown
Contributor

@svkrieger svkrieger commented Aug 23, 2022

Thanks for contributing to cloud_controller_ng. To speed up the process of reviewing your pull request please provide us with:

  • A short explanation of the proposed change:

This PR consists of two fixes.
One is adding a validation check to make sure that credentials, which have been sent with a SB update request, are not empty strings. From now on username and password must be non-empty strings, otherwise the validation will fail. This coding is executed by the API processes.

The other ensures that after a model layer validation error, the SB can be reset to its previous state. This coding is executed by the CC worker processes and is run during the delayed job execution of the broker.update job.

  • An explanation of the use cases your change solves

The issue is explained in #2937.

Registering a broker in CF with empty credentials never worked. In V2 and V3 an error will be returned. So it is okay to make non-empty credentials obligatory. The OSBAPI Spec says "While the communication between a Platform and Service Broker MAY be unsecure, it is RECOMMENDED that all communications between a Platform and a Service Broker are secured via TLS and authenticated."(source)

  • I have reviewed the contributing guide

  • I have viewed, signed, and submitted the Contributor License Agreement

  • I have made this pull request to the main branch

  • I have run all the unit tests using bundle exec rake

  • I have run CF Acceptance Tests

@svkrieger svkrieger force-pushed the issue-2937-fix-broker-lock-on-missing-credentials branch from 1c9a2fe to b0a9989 Compare August 24, 2022 08:22
Comment on lines 120 to +126
context 'when authentication is not valid' do
let(:request_body) do
valid_body[:authentication] = valid_body[:authentication].except(:type)
valid_body
end

before do
allow_any_instance_of(VCAP::CloudController::Validators::AuthenticationValidator).to receive(:validate) do |_, record|
record.errors.add(:authentication, 'this authentication is not valid!')
end
it 'is not valid' do
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a fix of a test which was wrong.
Context is 'when authentication is not valid' but the test ran with a valid_body. It was just green because the passed body didn't matter, because the validation was mocked. I changed the body to include an invalid authentication object by removing the mandatory type field. Also I removed the mock and checked for the correct error message, which is thrown by the validation in this case.

Comment on lines 150 to +159
context 'when authentication is not valid' do
let(:request_body) do
valid_body[:authentication] = valid_body[:authentication].except(:type)
valid_body
end

before do
allow_any_instance_of(VCAP::CloudController::Validators::AuthenticationValidator).to receive(:validate) do |_, record|
record.errors.add(:authentication, 'this authentication is not valid!')
end
it 'is not valid' do
expect(message).not_to be_valid
expect(message.errors_on(:authentication)).to include('authentication.type must be one of ["basic"]')
end
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same fix as in the other test file.

Comment on lines -185 to +186
# Make setting the state to 'AVAILABLE' fail, but nothing else
if record.state == 'AVAILABLE'
# Make setting the name to 'new-name' fail, but nothing else
if record.name == 'new-name'
Copy link
Copy Markdown
Contributor Author

@svkrieger svkrieger Aug 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far this test tested the only case in which the state of the SB could be reset to its previous state after a failed model validation. The broker update failed here. From then on the broker object will still have state = "AVAILABLE". In the rescue call, the broker's state will be explicitly set to the previous state and will overwrite the state AVAILABLE, which caused the model violation to fail (see here).
After changing the cause for the model violation to the name new-name, the test failed. This is because the broker.name will still be set to new-name, which previously caused the model violation. This leads to a failed broker.update in the rescue block as well. Therefore, the state cannot be reset to the previous state.

@svkrieger svkrieger marked this pull request as ready for review August 25, 2022 05:28
rescue => e
begin
broker.update(state: previous_broker_state)
initial_broker.update(state: previous_broker_state)
Copy link
Copy Markdown
Contributor Author

@svkrieger svkrieger Aug 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR fixes the issue, that the previous state could not be reset. Though I think it does not always make sense to let the broker return to the previous state.
For example when @catalog_updater.refresh fails to contact the broker to update the catalog and the previous_state was AVAILABLE, the broker would return to state AVAILABLE even it is not reachable at the moment. I think in this case setting the broker's state to SYNCHRONIZATION_FAILED would be more appropriate. This still allows for broker.update requests, but will let all service related operations fail fast.

Comment thread spec/unit/jobs/v3/services/update_broker_job_spec.rb Outdated
Comment thread app/jobs/v3/services/update_broker_job.rb Outdated
Comment thread app/jobs/v3/services/update_broker_job.rb Outdated
@svkrieger svkrieger force-pushed the issue-2937-fix-broker-lock-on-missing-credentials branch 2 times, most recently from b645146 to cd23682 Compare September 7, 2022 09:52
@svkrieger svkrieger force-pushed the issue-2937-fix-broker-lock-on-missing-credentials branch from cd23682 to c43a572 Compare September 7, 2022 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Service Broker locked in state SYNCHRONIZING after erroneous request

3 participants