Running `docker login` in a non-interactive environment sometimes errors
out if no username/pwd is provided. This handling is somewhat
inconsistent – this commit addresses that.
Before:
| `--username` | `--password` | Result |
|:------------:|:------------:| ------------------------------------------------------------------ |
| ✅ | ✅ | ✅ |
| ❌ | ❌ | `Error: Cannot perform an interactive login from a non TTY device` |
| ✅ | ❌ | `Error: Cannot perform an interactive login from a non TTY device` |
| ❌ | ✅ | hangs |
After:
| `--username` | `--password` | Result |
|:------------:|:------------:| ------------------------------------------------------------------ |
| ✅ | ✅ | ✅ |
| ❌ | ❌ | `Error: Cannot perform an interactive login from a non TTY device` |
| ✅ | ❌ | `Error: Cannot perform an interactive login from a non TTY device` |
| ❌ | ✅ | `Error: Cannot perform an interactive login from a non TTY device` |
It's worth calling out a separate scenario – if there are previous,
valid credentials, then running `docker login` with no username or
password provided will use the previously stored credentials, and not
error out.
```console
cat ~/.docker/config.json
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "xxxxxxxxxxx"
}
}
}
⭑ docker login 0>/dev/null
Authenticating with existing credentials...
Login Succeeded
```
This commit also applies the same non-interactive handling logic to the
new web-based login flow, which means that now, if there are no prior
credentials stored and a user runs `docker login`, instead of initiating
the new web-based login flow, an error is returned.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Normalization/converting the registry address to just a hostname happens
inside of `command.GetDefaultAuthConfig`. Use this value for the rest of
the login flow/storage.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This reverts commit e6624676e0.
Since e6624676e0, during login, we started
normalizing `registry-1.docker.io` to `index.docker.io`. This means that
if a user logs in with `docker login -u [username]
registry-1.docker.io`, the user's credentials get stored in
credhelpers/config.json under `https://index.docker.io/v1/`.
However, while the registry code normalizes an image reference without
registry (`docker pull alpine:latest`) and image references explicitly for
`index.docker.io` (`docker pull index.docker.io/library/alpine:latest`)
to the official index server (`https://index.docker.io/v1/`), and
fetches credentials for that auth key, it does not normalize
`registry-1.docker.io`, which means pulling explicitly from there
(`docker pull registry-1.docker.io/alpine:latest`) will not use
credentials stored under `https://index.docker.io/v1/`.
As such, until changes are made to the registry/pull/push code to
normalize `registry-1.docker.io` to `https://index.docker.io/v1/`, we
should not normalize this during login.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
This commit adds support for the oauth [device-code](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
login flow when authenticating against the official registry.
This is achieved by adding `cli/internal/oauth`, which contains code to manage
interacting with the Docker OAuth tenant (`login.docker.com`), including launching
the device-code flow, refreshing access using the refresh-token, and logging out.
The `OAuthManager` introduced here is also made available through the `command.Cli`
interface method `OAuthManager()`.
In order to maintain compatibility with any clients manually accessing
the credentials through `~/.docker/config.json` or via credential
helpers, the added `OAuthManager` uses the retrieved access token to
automatically generate a PAT with Hub, and store that in the
credentials.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
The fileStore itself is aware that it's insecure, so we can make it
responsible for printing the warning. It's not "perfect", as we use
`os.Stderr` unconditionally (not `dockerCli.Err()`), but probably won't
make a difference in _most_ cases.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Add an empty line before the warning to separate it from the command's output
- Use the `/go/` redirect URL that we have available.
- Put quotes around the filename used for storage.
- Use present tense for the message, as the message is printed while saving.
- User "credentials" instead of "password" for consistency with "credentials-store"
Before:
docker login myregistry.example.com
Username: thajeztah
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credential-stores
Login Succeeded
After:
docker login myregistry.example.com
Username: thajeztah
Password:
WARNING! Your credentials are stored unencrypted in '/root/.docker/config.json'.
Configure a credential helper to remove this warning. See
https://docs.docker.com/go/credential-store/
Login Succeeded
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If we fail to save credentials, make sure that the error about saving
doesn't get lost in the warning about credentials being stored unencrypted.
Also discard errors about printing the warning, as those would be unlikely,
and if they would occur, probably would fail to be printed as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the `XXXVar` equivalent for flags that don't have a shorthand flag
instead of passing an empty string for the shorthand flag.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Both these functions took the whole DockerCLI as argument, but only needed
the ConfigFile. ResolveAuthConfig also had an unused context.Context as
argument.
This patch updates both functions to accept a ConfigFile, and removes the
unused context.Context.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Older versions of Go do not format these comments, so we can already
reformat them ahead of time to prevent gofmt linting failing once
we update to Go 1.19 or up.
Result of:
gofmt -s -w $(find . -type f -name '*.go' | grep -v "/vendor/")
With some manual adjusting.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Prevent completion on "create" subcommands to prevent them
from completing with local filenames
- Add completion for "docker image save"
- Add completion for "docker image tag"
- Disable completion for "docker login"
- Exclude "paused" containers for "docker container attach" and
"docker container exec"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds a new annotation to commands that are known to be frequently
used, and allows setting a custom weight/order for these commands to
influence in what order they appear in the --help output.
I'm not entirely happy with the implementation (we could at least use
some helpers for this, and/or make it more generic to group commands
in output), but it could be a start.
For now, limiting this to only be used for the top-level --help, but
we can expand this to subcommands as well if we think it makes sense
to highlight "common" / "commonly used" commands.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove "Docker" from registry, as the registry specification is no
longer docker-specific, but part of the OCI distribution spec.
Also removed "Register" from one of the docs pages, as the login
command hasn't supported creating a new acccount on Docker Hub for
a long time.
I'm wondering if we should be more explicit about what log in / out
does (effectively; authenticate, and on success store the credentials
or token, and on log out; remove credentials/token).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI currenly calls the `/info` endpoint to get the address
of the default registry to use.
This functionality was added as part of the initial Windows implementation
of the engine. For legal reasons, Microsoft Windows (and thus Docker images
based on Windows) were not allowed to be distributed through non-Microsoft
infrastructure. As a temporary solution, a dedicated "registry-win-tp3.docker.io"
registry was created to serve Windows images.
As a result, the default registry was no longer "fixed", so a helper function
(`ElectAuthServer`) was added to allow the CLI to get the correct registry
address from the daemon. (docker/docker PR's/issues 18019, 19891, 19973)
Using separate registries was not an ideal solution, and a more permanent
solution was created by introducing "foreign image layers" in the distribution
spec, after which the "registry-win-tp3.docker.io" ceased to exist, and
removed from the engine through docker/docker PR 21100.
However, the `ElectAuthServer` was left in place, quoting from that PR;
> make the client check which default registry the daemon uses is still
> more correct than leaving it up to the client, even if it won't technically
> matter after this PR. There may be some backward compatibility scenarios
> where `ElectAuthServer` [sic] is still helpful.
That comment was 5 years ago, and given that the engine and cli are
released in tandem, and the default registry is not configurable, we
can save the extra roundtrip to the daemon by using a fixed value.
This patch deprecates the `ElectAuthServer` function, and makes it
return the default registry without calling (potentially expensie)
`/info` API endpoint.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit f32731f902 fixed a potential panic
when an error was returned while trying to get existing credentials.
However, other code paths currently use the result of `GetDefaultAuthConfig()`
even in an error condition; this resulted in a panic, because a `nil` was
returned.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This change refines the warning message returned during docker login to
only warn for unencrypted storage when the users password is being stored.
If the remote registry supports identity tokens, omit the warning,
since those tokens can be independently managed and revoked.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
This new collection of commands supports initializing a local
engine using containerd, updating that engine, and activating
the EE product
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
Since go 1.7, "context" is a standard package. Since go 1.9,
x/net/context merely provides some types aliased to those in
the standard context package.
The changes were performed by the following script:
for f in $(git ls-files \*.go | grep -v ^vendor/); do
sed -i 's|golang.org/x/net/context|context|' $f
goimports -w $f
for i in 1 2; do
awk '/^$/ {e=1; next;}
/\t"context"$/ {e=0;}
{if (e) {print ""; e=0}; print;}' < $f > $f.new && \
mv $f.new $f
goimports -w $f
done
done
[v2: do awk/goimports fixup twice]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This:
* conflicts with --password (naturally)
* conflicts with the absence of --username (both can't be grabbed by the
stdin)
* strips a trailing newline off the password if it exists
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
The `docker login -e` / `docker login --email` option was deprecated in
Docker 1.11 (https://github.com/moby/moby/releases/tag/v1.11.0) through
aee260d4eb3aa0fc86ee5038010b7bbc24512ae5 (April 2016), and when used has
been outputing a deprecation warning since;
Flag --email has been deprecated, will be removed in 17.06.
Originally this option was scheduled to be removed in docker 1.13, but
extended to docker 17.06 due to a change in our deprecation policy.
Given that only docker 1.10 and older use this flag (which is EOL, including
for CS versions, as of February 2017), will now be removed.
With this patch, `docker login` will now produce an Error if the flag
is used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
