cli/command: explicitly map AuthConfig fields instead of a direct cast #6516
Conversation
thaJeztah
added
status/2-code-review
kind/refactor
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
thaJeztah
force-pushed
the
authconfig_no_direct_cast
branch
3 times, most recently
from
1049a08 to
32dae45
Compare
Commit [cli@27b2797] forked the AuthConfig type from the API, and changed existing code to do a direct cast / convert of the forked type to the API type. This can cause issues if the API types diverges, such as the removal of the Email field. This patch explicitly maps each field to the corresponding API type, but adds some TODOs, because various code-paths only included a subset of the fields, which may be intentional for fields that were meant to be handled on the daemon / registry-client only. We should evaluate these conversions to make sure these fields should be sent from the client or not (and possibly even removed from the API type). [cli@27b2797]: docker@27b2797 Signed-off-by: Sebastiaan van Stijn <[email protected]>
thaJeztah
force-pushed
the
authconfig_no_direct_cast
branch
from
32dae45 to
9f02d96
Compare
| authCfg.ServerAddress = serverAddress | ||
| authCfg.IdentityToken = "" | ||
| return registrytypes.AuthConfig(authCfg), nil |
There was a problem hiding this comment.
Here, we're resetting this field, but other places we either copy everything as-is, and in yet other places, we only include Username, Password, and ServerAddress - this needs some digging into. I suspect the AuthConfig struct as defined in the API contains fields that were meant to be used by the registry client, and some fields not intended to be accepted through the X-Registry-Auth header.
| ServerAddress: serverAddress, | ||
|
|
||
| // TODO(thaJeztah): Are these expected to be included? | ||
| Auth: authCfg.Auth, | ||
| IdentityToken: "", | ||
| RegistryToken: authCfg.RegistryToken, |
There was a problem hiding this comment.
More so, because the Auth field .. I think is the base64 encoded representation of Username:Password, so either the structured fields OR only the Username:Password should likely be sent.
3 participants
relates to:
Commit cli@27b2797 forked the AuthConfig type from the API, and changed existing code to do a direct cast / convert of the forked type to the API type. This can cause issues if the API types diverges, such as the removal of the Email field.
This patch explicitly maps each field to the corresponding API type, but adds some TODOs, because various code-paths only included a subset of the fields, which may be intentional for fields that were meant to be handled on the daemon / registry-client only.
We should evaluate these conversions to make sure these fields should be sent from the client or not (and possibly even removed from the API type).
- What I did
- How I did it
- How to verify it
- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)