-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Cannot download packages from private PyPi repository using HTTP basic auth with Poetry 1.1.0 + old v1.0.x PypiCloud w/ default settings #3041
Comments
@MasterNayru interesting. We recently identified that in Am I correct in understanding that in your case; authentication is used to retrieve wheel direct links (ie. incl. tokens) but the expectation is that we do not send basic auth when downloading these wheels? If so, this is a bit tricky, as this would mean there are 2 use cases that are not necessarily compatible with each other. |
@abn I am expecting that if I am trying to download packages from S3 that, since pypicloud returns a URL with the necessary auth parameters in the download URL from the API requests, and since S3 seems to error out when the username/password auth parameters are provided, that they will somehow not be used as part of the requests for the downloads, which seemed to fit in line pretty well with the behaviour in the older versions. |
@abn I am going to close this issue as it would appear that pypicloud have, since I last looked at it, defaulted to the behaviour which poetry is enforcing with regards to auth for package downloads. Rather than try to support the old behaviour which pip works with, I will update my pypicloud installation and make use of the new behaviour. Cheers for bearing with us. |
We hit exactly the same problem with poetry 1.1.1 and pypicloud 1.0.10.
Since it's poetry/requests who adds the authorization header, I don't see how this can be fixed on pypicloud side. Please correct me (or reopen the issue 😉 ). |
pypicloud 1.0.11 introduced the ability to stream files through pypicloud. By briefly looking at the diff, it seems like we can configure pypicloud with We'll try pypicloud bump and report back. |
Hi. Ran into the same issue. Tried both with and without Error is because of the headers being sent. The same url is downloadable using
|
@MasterNayru I would suggest that this issue should be considered as poetry issue. The reason being - same We run number of repositories and python packages, only one of them is with poetry and currently it does not work. We should either wait or help with fixing poetry or migrate to pip. |
@Katafalkas one aspect to note here is that Considering that Out of curiosity, are the domains different for the index and the file? |
They are for us (also using |
The url of pypi-cloud server and the file served from S3 are different by default, but there is an option to passthrough url. Which makes both of those URLs the same. |
This is how I setup private pypi
@MeanderingCode let me know if this one works for you |
@cereblanco Thank you. I discovered this yesterday when looking at changes related to legacy repositories. Edited my comment on your PR. |
Hi, I tested your method and it did not work for me. My server should not return a 500 error, but the previous versions were not trying to download other packages from my private repo.
Here is my pyproject.toml .
|
I think we should consider reopening this issue as this problem still exists when using a pypi server that returns presigned urls to be used when fetching packages (for instance pypi-cloud) Right now I'm forced to stick with |
Same for me, forced to stick with |
Also experiencing the same problem. We have tried to configure |
I wouldn't mind helping out fixing this issue but then I need to know that the poetry community actually considers this as a bug. I would also like some context. What was changed and why in |
The fix is to make pypicloud stop returning pre-signed URLs to pip. Python package management tools are enough of a mess without having to assume that the auth for package information retrieval is different from the auth needed for package downloads. This is the way pypi.org works and having to assume that auth maybe is or is not the same is the kind of thing that makes these package manager tools an absolute mess. The whole reason why it returned pre-signed URLs by default was because easy_install wouldn't work without it. I wish I was kidding. https://pypicloud.readthedocs.io/en/latest/topics/redirect_urls.html#redirect-detail In pypicloud v1.0.14 (in a patch change, I guess they aren't doing the whole semver thing), https://pypicloud.readthedocs.io/en/latest/changes.html#id9 they changed the config value I haven't needed to change this setting myself as I fixed the issue by just updating pypicloud to a version where it was set to True by default, but that is the setting you would need to change. Haven't had an issue with it since. |
This was very interesting news! We're running pypi cloud Which version of pypi cloud are you using btw? Our config looks like this: [app:main]
use = egg:pypicloud
redirect_urls = true
pypi.fallback = cache
pypi.always_show_upstream = True
pypi.stream_files = True
pypi.package_max_age = 604800
pypi.storage = s3
storage.bucket = S3_BUCKET
storage.region_name = eu-west-1
pypi.db = redis
db.url = REDIS_URL |
UPDATE: Things actually works! We were indeed running an old version of pypi cloud. After updating to 1.1.17 things actually started to work! 🌟 |
Great to hear that it is working for you. The setting you would have needed to set was |
Thanks! Yes I actually figured that out after your previous reply 🙏 Thanks a lot! |
I'm getting the exact same issue but using myget.org instead. The "solution" here is specific to pypicloud but the underlying issue of a package download being redirected to a different URL with auth baked in remains. I imagnee this issue will only grow as services use managed S3 style storage more and more. Can this be re-opened and fixed "properly"? |
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in python-poetry#3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in python-poetry#3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in python-poetry#3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in python-poetry#3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in python-poetry#3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This change refactors HTTP repository source implementations. The following changes have been made. - CacheControl cache now lives within Authenticator. - Authenticator manages unique sessions for individual netloc. - CacheControl usage now respects disable cache parameter in repos. - Certificate and authentication logic is now managed solely within Authenticator for source repositories taking advantage of recent enhancements. These changes should allow for better handling of cases like those described in #3041. Additionally, this forms the foundation for unifying HTTP specific logic within the code base and possibly allowing for migration of requests etc. if/when required.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
-vvv
option).Issue
We have been using Poetry to pull down packages from a private PyPi repository and everything has been working fine until Poetry 1.1.0. We are configuring poetry to talk to our private PyPi installation by HTTP basic auth, and that auth works perfectly fine to resolve which versions of a package to install. The problem seems to be that that same auth is then used in the requests to download wheels from PyPi, which causes the following error to occur:
If I change the following lines in the poetry code:
changes to:
and re-run, everything works:
It seems like the auth is needed to talk to the API for package version resolution but causes issues when it is also used for package downloads. If it makes any difference, I am using pypicloud as the backend for my private PyPi installation.
I am trying to be as brief as possible with my output as possible without dumping any keys or stuff like that. Please let me know if you need any more information or suggestions on what I should be changing in my configuration to get my stuff working again.
The text was updated successfully, but these errors were encountered: