Skip to content

ignore content_type from credentials provider #106

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

Merged
merged 1 commit into from
Jan 17, 2023

Conversation

VasilyStepanov
Copy link
Contributor

I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en

Yes!

Pull request type

Please check the type of change your PR introduces:

  • Bugfix
  • Feature
  • Code style update (formatting, renaming)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • Documentation content changes
  • Other (please describe):

What is the current behavior?

Default metadata credentials provider in yandex cloud environment (http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token) returns access token in json format, but with text/plain content type.
This is wrong, but code from iam.auth.MetadataUrlCredentials._make_token_request() ignores content type and everything works fine in sync implementation.
On the other hand, its async alternative aio.iam.MetadataUrlCredentials._make_token_request() fails with wrong content type error.

Issue Number: N/A

What is the new behavior?

Now we ignore content type from metadata credentials provider. This is also wrong, but acceptable, since sync implementation also do this.

Other information

Copy link
Member

@rekby rekby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello, @VasilyStepanov.

Thanks for the fix :)

@rekby rekby merged commit 21725e6 into ydb-platform:main Jan 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants