poetry install authentication issue with http-basic private index (in devcontainer)
#9079
Comments
ckchow
added
kind/bug
|
Perhaps your credentials have permissions in one of those places but not the other Perhaps one of them is being answered from cache Unless you can provide a way to reproduce this, it is unlikely that we can guess what you are seeing |
|
The credentials work on all the URLs listed, I tried them in my browser and was able to download the artifacts. Probably not answered from cache, this behavior happens in a completely fresh I was chatting in discord with abn and they mentioned that it might be possible to repro and test this with a devpi test fixture. |
|
Sure, if you can provide a repro that way, that works. Lots of us use credentials for private repositories all the time, so I have to guess this is likely to be something specific to you. I think there is a good chance you will find it difficult to set up a repro - but if so, hopefully in trying you will learn something about what it is that is unusual in your environment. |
|
Maybe it's washed out in the report details, but the fact that |
|
I can confirm we are also running into private package authentication issues in our CI pipeline runs. We have narrowed it down to poetry 1.8.x being the cause. When we pin the poetry version to 1.7.1, it installs perfectly fine. But as soon as the version isn't pinned and the pipeline install poetry 1.8.x, then the authorization fails. Please see below: - task: PipAuthenticate@1
displayName: 'Pip Authentication'
inputs:
artifactFeeds: '<feed_name>'
onlyAddExtraIndex: true
- script: |
curl -sSL https://install.python-poetry.org | python3 -
export PATH=$PATH:$HOME/.poetry/bin
export PAT=$(echo "$PIP_EXTRA_INDEX_URL" | sed -n 's/.*build:\([^@]*\)@.*/\1/p')
poetry config http-basic.<source_name> $PAT ""
poetry install
displayName: 'Install dependencies'
Work around: Pin the version of poetry to 1.7.1 - task: PipAuthenticate@1
displayName: 'Pip Authentication'
inputs:
artifactFeeds: '<feed_name>'
onlyAddExtraIndex: true
- script: |
curl -sSL https://install.python-poetry.org | python3 - --version 1.7.1
export PATH=$PATH:$HOME/.poetry/bin
export PAT=$(echo "$PIP_EXTRA_INDEX_URL" | sed -n 's/.*build:\([^@]*\)@.*/\1/p')
poetry config http-basic.<source_name> $PAT ""
poetry install
displayName: 'Install dependencies'
|
@Garett601 can you please provide the |
|
We're seeing similar on v1.8.2, when installing locally on a Windows machine, trying to authenticate to an AWS CodeArtifact repo. I think it may have something to do with the length of the token provided by CodeArtifact (but this wasn't an issue with earlier Poetry versions). If I specify the source as follows in pyproject.toml, then run 'poetry lock', then 'poetry install', I get the 401 issue: [[tool.poetry.source]] I have tried this by passing creds via 'poetry config http-basic.aws aws $token', including with the keychain disabled, and as environment variables. If instead I set the source as follows in pyproject.toml, then run 'poetry lock', then 'poetry install', it works: [[tool.poetry.source]] NB The sha256 values of each package in the lock file do not change between the two variants of pyproject.toml following 'poetry lock'. They are valid. Only package.source.url varies. The verbose logging for the error is: PS C:\Code\xxx> poetry install -vvv Finding the necessary packages for the current system Package operations: 54 installs, 0 updates, 0 removals, 1 skipped
Stack trace: 11 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:281 in _execute_operation 10 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:391 in _do_execute_operation 9 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:516 in _execute_install 8 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:554 in _install 7 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:746 in _download 6 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:753 in _download_link 5 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\cache.py:272 in get_cached_archive_for_link 4 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\installation\executor.py:821 in _download_archive 3 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\helpers.py:177 in init 2 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\authenticator.py:267 in get 1 ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\poetry\utils\authenticator.py:245 in request HTTPError 401 Client Error: Unauthorized for url: https://ourpypi-123456789012.d.codeartifact.eu-west-2.amazonaws.com/pypi/ourpypi/simple/six/1.16.0/six-1.16.0-py2.py3-none-any.whl#sha256=8abb2f1d86890a2dfb989f9a77cfcfd3e47c2a354b01111771326f8aa26e0254 at ~\AppData\Roaming\pypoetry\venv\Lib\site-packages\requests\models.py:1021 in raise_for_status Cannot install six. |
I also thought this was the issue, and checked the PAT length as a debug step, and it did seem like an odd length (But this was the same as before and it works perfectly with poetry 1.7.1) |
|
Just to say that I got past this issue, for the time being, by uninstalling and reinstalling Poetry (current version, 1.8.2) on my Windows machine. I have successfully with both PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring (as per OP) and poetry config keyring.enabled false. Both result in the creds being stored in plaintext in auth.toml, which is fine for now. It is just a suspicion and not something I can follow up on, but the trigger for this behaviour may have been when we tried authenticating to CodeArtifact with a token longer than allowed by keychain on Windows, which from one report is 1280 characters. Seems that CodeArtifact tokens are around 1400 chrs when authenticating via a role, vs ~1200 chrs when authenticating via a user. I saw the same behaviour then as described in this issue: #6597. Since then, and until reinstalling, this current issue has been in play. |
|
I encounter the same issue in a |
|
@Garett601 - perhaps your issue is the same as one that I've encountered. I see in your config you use an empty password:
Gemfury recommends the same pattern (https://gemfury.com/help/errors/repo-url-password/) and my builds also started failing after upgrading to 1.8. I set the token to the auth user via environment in our dockerfiles, and do not set a password: # Export fury auth to poetry
ARG fury_auth
ENV POETRY_HTTP_BASIC_FURY_USERNAME ${fury_auth}Seems to originate in e4cf218 where I think it is this change that is responsible for the difference. Prior, if a username is set but no password, poetry/src/poetry/utils/password_manager.py Lines 205 to 217 in 7243b94 After, if no password is set and there is no keyring backend available, this method now returns poetry/src/poetry/utils/password_manager.py Lines 199 to 214 in e4cf218 My workaround is to set both the username and password for auth, which is also supported for my case. |
Secrus
added
area/auth
This change fixes a regression in the password manager that disallowed the use of empty username or password as required by some self-hosted repositories. Relates-to: python-poetry#9079 python-poetry#2538
This change fixes a regression in the password manager that disallowed the use of empty username or password as required by some self-hosted repositories. Relates-to: python-poetry#9079 python-poetry#2538
This change fixes a regression in the password manager that disallowed the use of empty username or password as required by some self-hosted repositories. Relates-to: python-poetry#9079 python-poetry#2538
This change fixes a regression in the password manager that disallowed the use of empty username or password as required by some self-hosted repositories. Relates-to: python-poetry#9079 python-poetry#2538
This change fixes a regression in the password manager that disallowed the use of empty username or password as required by some self-hosted repositories. Relates-to: python-poetry#9079 python-poetry#2538
Description
Using
poetry installin a context without a keyring backend (in this case a devcontainer), trying to pull packages from a private http-basic secured pypi, causes 401 unauthorized in the install process.poetry lockworks, and certain GETs earlier inpoetry installsucceed as well.devcontainer.json
dockerfile.txt
Workarounds
PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring poetry install -vvvworksPoetry Installation Method
pipx
Operating System
Linux 43d0d0761105 6.5.0-15-generic #15-Ubuntu SMP PREEMPT_DYNAMIC Tue Jan 9 22:39:36 UTC 2024 x86_64 GNU/Linux
Poetry Version
1.8.1, 1.7.1
Poetry Configuration
Example pyproject.toml
Poetry Runtime Logs
later
The text was updated successfully, but these errors were encountered: