Description of the issue:
Failed to connect to docker registry using Basic Authentication
Expected behavior:
jib is able to connect to the registry
Steps to reproduce:
Setup a docker registry using https with basic authentication
Pull an image using
Environment:
Windows 10
Maven 3.5.3
Log output:
[ERROR] Failed to execute goal com.google.cloud.tools:jib-maven-plugin:0.9.2:build (default-cli) on project testing: Build image failed: Tried to retrieve authentication method for myregistry:1234 but failed because: Failed get authentication method from 'WWW-Authenticate' header | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new: Failed to authenticate with the registry because: 'Bearer' was not found in the 'WWW-Authenticate' header, tried to parse: BASIC realm="Sonatype Nexus Repository Manager" -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.google.cloud.tools:jib-maven-plugin:0.9.2:build (default-cli) on project testing: Build image failed
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: Build image failed
at com.google.cloud.tools.jib.maven.BuildImageMojo.execute(BuildImageMojo.java:132)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
Caused by: com.google.cloud.tools.jib.registry.RegistryErrorException: Tried to retrieve authentication method for nexus:6666 but failed because: Failed get authentication method from 'WWW-Authenticate' header | If this is a bug, please file an issue at https://github.com/GoogleContainerTools/jib/issues/new
at com.google.cloud.tools.jib.registry.RegistryErrorExceptionBuilder.build(RegistryErrorExceptionBuilder.java:108)
at com.google.cloud.tools.jib.registry.AuthenticationMethodRetriever.handleHttpResponseException(AuthenticationMethodRetriever.java:104)
at com.google.cloud.tools.jib.registry.AuthenticationMethodRetriever.handleHttpResponseException(AuthenticationMethodRetriever.java:31)
at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:176)
at com.google.cloud.tools.jib.registry.RegistryEndpointCaller.call(RegistryEndpointCaller.java:139)
at com.google.cloud.tools.jib.registry.RegistryClient.callRegistryEndpoint(RegistryClient.java:321)
at com.google.cloud.tools.jib.registry.RegistryClient.getRegistryAuthenticator(RegistryClient.java:177)
at com.google.cloud.tools.jib.registry.RegistryAuthenticators.forOther(RegistryAuthenticators.java:48)
at com.google.cloud.tools.jib.builder.steps.AuthenticatePushStep.call(AuthenticatePushStep.java:82)
at com.google.cloud.tools.jib.builder.steps.AuthenticatePushStep.call(AuthenticatePushStep.java:43)
at com.google.common.util.concurrent.CombinedFuture$CallableInterruptibleTask.runInterruptibly(CombinedFuture.java:181)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:57)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.google.cloud.tools.jib.registry.RegistryAuthenticationFailedException: Failed to authenticate with the registry because: 'Bearer' was not found in the 'WWW-Authenticate' header, tried to parse: BASIC realm="Sonatype Nexus Repository Manager"
at com.google.cloud.tools.jib.registry.RegistryAuthenticator.newRegistryAuthenticationFailedException(RegistryAuthenticator.java:87)
at com.google.cloud.tools.jib.registry.RegistryAuthenticator.fromAuthenticationMethod(RegistryAuthenticator.java:65)
at com.google.cloud.tools.jib.registry.AuthenticationMethodRetriever.handleHttpResponseException(AuthenticationMethodRetriever.java:98)
... 13 more
Additional Information:
Ah, looks like some server responds with BASIC in all caps.
Ah, yes our RegistryAuthenticator can only handle Basic and not in all caps (RFC 2617 says it should be case-insensitive). Looks like we should probably try fixing this with deprecating our custom RegistryAuthenticator (#479).
I created a patch in this Repo. I can't get the tests running on my system, it would be awesome if someone could run them for me : ).
I have tested it and the fix is good.
The fix was merged and we will be cutting a release with the fix in version 0.9.4 soon :)
Maybe it makes sense to do the same with BEARER, but I see the code path is not critical.
+1 Yea, we should do it for bearer too.