This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
Remove resetting Auth credentials in reverse-proxy #1349
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: #979
Description
This PR removes setting Auth credentials in reverse-proxy.
@andrein was right about the fact that lines
orchestrator/go/http/raft_reverse_proxy.go
Lines 42 to 45 in d536bc6
reset auth credentials for every request going through
reverse-proxy
and therefore provide this request read/write permissions even for areadonly
user.These lines are unnecessary, because there are 3 basic scenarios:
401 Unauthorized
. In this case we shouldn't care about proxying, because it never reaches the proxy."AuthenticationMethod": "multi"
and a leader has"AuthenticationMethod": "basic"
. But that isn't a proxy problem.Testing
During the whole testing both servers had the following configuration:
Before fix behaviour (Orchestrator version built from the latest
master
state):Request to the leader is rejected, because it's executed as
readonly
, but the same request sent to the follower is accepted, because its user is implicitly changed todba_team
by reverse-proxy.After fix behaviour:
Since credentials are not rewritten by reverse-proxy, both requests produce expected results.
To ensure that we didn't break actual functionality, let's execute a valid request through a follower:
It shows that the request was relayed and executed successfully.