Skip to content
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

Access keyring only when needed. #8078

Conversation

real-yfprojects
Copy link
Contributor

Pull Request Check List

Resolves: #1917

  • Added tests for changed code.
  • Updated documentation for changed code.

Requesting a network page is first tried without retrieving authentication from the keyring. Credentials provided by other means are used already. If no authentication was found and the server answers with 401 or 403 the keyring is queried for credentials. This fixes #1917.

  • src/poetry/utils/constants.py (STATUS_AUTHLIST): A list of HTTP errors requesting authentication. Currently 401 and 403.

  • src/poetry/utils/authenticator.py (Authenticator.request): Retrieve credentials with disabled keyring first. On auth error try again with enabled keyring.

  • src/poetry/utils/authenticator.py (Authenticator.get_credentials_for_url): Add keyring option.

  • src/poetry/utils/authenticator.py (Authenticator._get_credentials_for_url: ^^^ same as above

  • src/poetry/utils/authenticator.py (Authenticator._get_credentials_for_repository): ^^^

  • src/poetry/utils/authenticator.py (AuthenticatorRepositoryConfig.get_http_credentials): ^^^

  • src/poetry/utils/password_manager.py (PasswordManager.get_http_auth): ^^^

@real-yfprojects
Copy link
Contributor Author

There is already #7037 and #6612 that try to fix this issue. However they seem to take a different approach. Instead of fixing that poetry tries to get credential although it doesn't need them, they only fix that poetry complains about a locked keyring.

@real-yfprojects real-yfprojects marked this pull request as draft June 8, 2023 20:31
@real-yfprojects
Copy link
Contributor Author

Oh I forgot to fix some existing tests. However I am unsure what I should add new tests for?
I also couldn't find any documentation that has to be updated.

@real-yfprojects real-yfprojects force-pushed the keyring-on-demand branch 2 times, most recently from 270d666 to 8bfde6f Compare June 8, 2023 22:00
@real-yfprojects real-yfprojects marked this pull request as ready for review June 8, 2023 22:08
@real-yfprojects
Copy link
Contributor Author

I just noticed #7038 does something similar. So what has to be changed so that poetry behaves as you wish?

@dimbleby
Copy link
Contributor

dimbleby commented Jun 9, 2023

imo #6612 and #7037 look like a more pragmatic approach

in particular #6612 doesn't seem like it needs to be much better to be mergeable: catch a slightly more general exception and add a unit test and - noting that I don't have the power to make such decisions - it would look to me to be good to go

@real-yfprojects
Copy link
Contributor Author

Quoting from #7037:

I think Poetry shouldn't request access to the keyring before the remote server has actually asked for credentials, but this can be done in a subsequent change. #1917 is affecting many users.

That's what I thought too. So I wrote this patch. From my point of view this PR can be merged immediately.

As @remram44 said, fixing poetries elaborate keyring usage is inevitable. I don't want to deny a keyring request every time I run poetry.

@real-yfprojects
Copy link
Contributor Author

real-yfprojects commented Jun 9, 2023

From my point of view this PR can be merged immediately.

I just noticed ci is failing for some reason. Didn't it pass yesterday when I finished work on this PR? It did. But then I slightly adjusted the list of status codes without updating the corresponding test.

Requesting a network page is first tried without retrieving authentication from the keyring.
Credentials provided by other means are used already.
If no authentication was found and the server answers with 401 or 403 the keyring is queried for credentials.
This fixes python-poetry#1917.

* src/poetry/utils/constants.py (STATUS_AUTHLIST): A list of HTTP errors requesting authentication. Currently 401 and 403.

* src/poetry/utils/authenticator.py (Authenticator.request): Retrieve credentials with disabled keyring first. On auth error try again with enabled keyring.

* src/poetry/utils/authenticator.py (Authenticator.get_credentials_for_url): Add `keyring` option.
* src/poetry/utils/authenticator.py (Authenticator._get_credentials_for_url: ^^^ same as above
* src/poetry/utils/authenticator.py (Authenticator._get_credentials_for_repository): ^^^
* src/poetry/utils/authenticator.py (AuthenticatorRepositoryConfig.get_http_credentials): ^^^
* src/poetry/utils/password_manager.py (PasswordManager.get_http_auth): ^^^

* src/poetry/utils/password_manager.py (HTTPAuthCredential): Implement `empty` property that one of username or password exists.

* src/poetry/utils/authenticator.py (Authenticator): Use `HTTPAuthCredential.empty`. Only cache non-empty credentials.

* tests/utils/test_authenticator.py : Fix tests.
@dimbleby
Copy link
Contributor

dimbleby commented Jun 9, 2023

So far as I can see #7038 was not merged because hitting every API twice - first to try without authentication and then with - was considered not OK. SInce this does exactly the same I don't know why it wouldn't meet the same fate.

@real-yfprojects
Copy link
Contributor Author

First to try without authentication and then with - was considered not OK. SInce this does exactly the same I don't know why it wouldn't meet the same fate.

Well then discuss how poetry should behave instead - here or in a separate issue.

@dimbleby
Copy link
Contributor

dimbleby commented Jun 9, 2023

... that's exactly what #8078 (comment) was doing!

@real-yfprojects
Copy link
Contributor Author

real-yfprojects commented Jun 9, 2023

... that's exactly what #8078 (comment) was doing!

Great! However I didn't notice you were discussing which poetry behaviour would be favourable. You seemed to discuss which PR would be more pragmatic to merge or a better fix for #1917. I would like to separate these two discussions. #6612 seems better suited for a quick fix and I advocate merging it. Moreover I don't mind when this PR isn't merged in its current form. However we shouldn't leave sight of the bigger picture.

Regarding #6612 I will take a look whether I can take the branch, finish the patch and open a new PR.

@felix-ht
Copy link

felix-ht commented Jul 21, 2023

So far as I can see #7038 was not merged because hitting every API twice - first to try without authentication and then with - was considered not OK. SInce this does exactly the same I don't know why it wouldn't meet the same fate.

They main issue is that peotry tries to get a password for any http request from the keyring. It just looks at the keyring and checks if there is a password for the netloc of the current request. This automatic checking happens for any and all http requests.

There is also no duplicated api requets. If you do not either configure a http_fallback (use the netloc password store in the keyring) or explicitly set a password through poetry, the request will just fail with unauthorised.

Having some poeple properly configure their password proteced routes vs breaking the workflow for most users seems like a very good trade off to me.

I don't get why nobody seems to care about 9th most upvoted issues of poetry :/
There are a ton of PRs, from many new contributors but nothing is happening, and the PRs keep rotting while the Problem persists. This is a very bad experience for a first time contributor.

@real-yfprojects
Copy link
Contributor Author

I don't get why nobody seems to care about 9th most upvoted issues of poetry :/

At least none of the maintainers although this would be exactly where a maintainer has to step in. Instead they seem to dodge the hard decisions.

@remram44
Copy link
Contributor

Asking for credentials after hitting 401 is a best practice if interactivity with the user is required. It is how every browser works. I'm fact it is the only thing the 401 code is for.

I'm not sure why Poetry maintainers would object to getting that response first?

@real-yfprojects
Copy link
Contributor Author

I'm not sure why Poetry maintainers would object to getting that response first?

Not sure whether @neersighted is a maintainer. However he did object in #7038 (comment).

@dimbleby
Copy link
Contributor

per #8078 (comment): IMO a moderately improved #6612 ought to be mergeable.

(so far as I know no-one has offered such an MR)

@remram44
Copy link
Contributor

The comment you link is from yourself, not a maintainer...

No one is going to offer more MRs now that 3 have been rejected and maintainers are silent on what they might find acceptable. I take offense at your suggestion that this is what is stopping progress.

At this point, I am running my own forked version on all my desktop computers. That's the beauty of open source: when a project goes silent or hostile, and is utterly broken for your purpose, you can patch it yourself. It is clear we are in this situation.

@dimbleby
Copy link
Contributor

The comment you link is from yourself, not a maintainer...

er, yes. I am reiterating my opinion. While not a maintainer, I am a regular contributor and have a reasonable sense of what is likely to be acceptable.

No one is going to offer more MRs now ...

well hopefully you are wrong; certainly no fix will happen if no fix is made.

@real-yfprojects
Copy link
Contributor Author

per #8078 (comment): IMO a moderately improved #6612 ought to be mergeable.

(so far as I know no-one has offered such an MR)

Well I have offered help to improve set PR. However I stumbled upon an issue I need help with before writing the code. See #6612 (comment)

Copy link

github-actions bot commented Mar 3, 2024

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 3, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Keyring errors during non-publishing operations
5 participants