This repository has been archived by the owner on Apr 14, 2021. It is now read-only.
When a 401 response is received, raise BadAuthenticationError if credentials were present in the request URI #6928
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for opening a pull request and helping make Bundler better! Someone from the Bundler team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality. We use Travis CI to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of Travis CI in the PR status window below. If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #bundler channel on Slack. For more information about contributing to the Bundler project feel free to review our CONTRIBUTING guide |
segiddins
reviewed
Jan 27, 2019
deivid-rodriguez
approved these changes
Apr 26, 2019
|
No further feedback so going in! @bundlerbot r+ |
ghost
pushed a commit
that referenced
this pull request
Apr 28, 2019
6928: When a 401 response is received, raise BadAuthenticationError if credentials were present in the request URI r=deivid-rodriguez a=jdliss ### What was the end-user problem that led to this PR? Some gem servers respond to bad username/password request with a 401 instead of a 403. ### What was your diagnosis of the problem? When a 401 response was received, bundler would automatically assume no credentials were supplied, leading to a response of ``` Authentication is required for http://moto@gems.motologic.com/. Please supply credentials for this source. You can do this by running: bundle config http://moto@gems.motologic.com/ username:password ``` even when a username and password was present in the bundler config. ### What is your fix for the problem, implemented in this PR? There already exists a check for credentials in the request URI for 403 responses. I took that pattern and implemented it for 401 responses as well. ### Why did you choose this fix out of the possible options? I chose this fix because a very similar pattern already exists in bundler, I just applied the same logic to another response code. Co-authored-by: Jonathan <jonacom@lissismore.com>
Build succeeded |
ghost
merged commit
This pull request was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
What was the end-user problem that led to this PR?
Some gem servers respond to bad username/password request with a 401 instead of a 403.
What was your diagnosis of the problem?
When a 401 response was received, bundler would automatically assume no credentials were supplied, leading to a response of
even when a username and password was present in the bundler config.
What is your fix for the problem, implemented in this PR?
There already exists a check for credentials in the request URI for 403 responses. I took that pattern and implemented it for 401 responses as well.
Why did you choose this fix out of the possible options?
I chose this fix because a very similar pattern already exists in bundler, I just applied the same logic to another response code.