When we already have a token for the first repository after probing
for no-auth authenticator or testing user-entered credentials, just
use that, don't request it again in the loop over repositories.
This gives a significant optimization of the prompted-credentials
case for registry.redhat.io, which takes 4-5 seconds to generate a
token, hopefully avoiding the user thinking something has gone wrong.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
Fix problems overwriting a GError when we retry multiple times.
One of these was introduced with the recent change
e3f17a89a flatpak-oci-authenticator: try getting a token without credentials
but the other was existing.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
Some registries require getting a token even to download an image
anonymously. So, if no auth has been configured, before prompting
the user for username/password, try without a BasicAuth header.
Signed-off-by: Owen W. Taylor <otaylor@fishsoup.net>
We rely on broadcast signals for authenticator replies rather than unicast
as these are not filtered by the sandbox (due to them being opt-in by the
receiver).
Actually this already worked fine in the flatpak side as the generated
code already subscribes to the signals, this just switches the internal
authenticators (test and oci) to using the new way to emit signals.
We look in these, in this order:
~/.config/flatpak/oci-auth.json
/etc/flatpak/oci-auth.json
/run/user/$uid/containers/auth.json
/run/containers/$uid/auth.json
~/.docker/config.json
The first two are flatpak specific, and the others are what
skopeo and docker use.
Given a configuration like:
[remote "oci-remote"]
url=oci+http://some.server.com/api/v1/organization/foo?index=labels
xa.authenticator-name=org.flatpak.Authenticator.Oci
xa.default-token-type=1
xa.authenticator-options={"auth": <"a-token-here">}
I was able to install an app from an OCI remote that required a login
