Keycloak 17.0.0 results in "page not found" for admin url

I have tried the following Docker image and the download zip of version 17.0.0 and I get the same results

On using the URL http://localhost:8080/auth/admin I get a “page not found” message.
Note: this is not https

Here is the log file when the error occurs…

2022-02-17 12:57:52,619 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (executor-thread-3) new JtaTransactionWrapper
2022-02-17 12:57:52,619 DEBUG [org.keycloak.transaction.JtaTransactionWrapper] (executor-thread-3) was existing? false
2022-02-17 12:57:52,620 DEBUG [org.keycloak.services.error.KeycloakErrorHandler] (executor-thread-3) Error response 404: javax.ws.rs.NotFoundException: RESTEASY003210: Could not find resource for full path: http://localhost:8080/auth/admin
	at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:152)
	at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:74)
	at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:47)
	at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:480)
	at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:332)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:253)
	at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:161)
	at org.jboss.resteasy.core.interception.jaxrs.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:364)
	at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:164)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:247)
	at io.quarkus.resteasy.runtime.standalone.RequestDispatcher.service(RequestDispatcher.java:73)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.dispatch(VertxRequestHandler.java:151)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.handle(VertxRequestHandler.java:82)
	at io.quarkus.resteasy.runtime.standalone.VertxRequestHandler.handle(VertxRequestHandler.java:42)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1212)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:163)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:141)
	at io.quarkus.vertx.http.runtime.StaticResourcesRecorder$2.handle(StaticResourcesRecorder.java:67)
	at io.quarkus.vertx.http.runtime.StaticResourcesRecorder$2.handle(StaticResourcesRecorder.java:55)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1212)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:163)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:141)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder$5.handle(VertxHttpRecorder.java:362)
	at io.quarkus.vertx.http.runtime.VertxHttpRecorder$5.handle(VertxHttpRecorder.java:340)
	at io.vertx.ext.web.impl.RouteState.handleContext(RouteState.java:1212)
	at io.vertx.ext.web.impl.RoutingContextImplBase.iterateNext(RoutingContextImplBase.java:163)
	at io.vertx.ext.web.impl.RoutingContextImpl.next(RoutingContextImpl.java:141)
	at org.keycloak.quarkus.runtime.integration.web.QuarkusRequestFilter.lambda$createBlockingHandler$1(QuarkusRequestFilter.java:66)
	at io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:159)
	at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
	at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:157)
	at io.quarkus.vertx.core.runtime.VertxCoreRecorder$13.runWith(VertxCoreRecorder.java:543)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
	at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
	at org.jboss.threads.ThreadLocalResettingRunnable.run(ThreadLocalResettingRunnable.java:29)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:829)

2022-02-17 12:57:52,625 DEBUG [freemarker.cache] (executor-thread-3) Couldn't find template in cache for "error.ftl"("en_GB", UTF-8, parsed); will try to load it.
2022-02-17 12:57:52,625 DEBUG [freemarker.cache] (executor-thread-3) TemplateLoader.findTemplateSource("error_en_GB.ftl"): Not found

I have started the service via this command…

./kc.sh start-dev --log-level=DEBUG

Version: keycloak-17.0.0.zip

Any ideas on how to resolve this?

Thanks
Jeff


I have just found the following bug raised:

1 Like

The new default path in keycloak 17 is /. You can updated it to the old one with the --hostname-path=/auth flag.

2 Likes

Hi @xgp , after building and starting keycloak with --hostname-path=/auth flag and trying to open the Administration Console, I get redirected to http://localhost:8080/auth/admin/ which returns “Page not found”.

Any idea ?

Send your whole startup command so that I can debug.

After ./kc.sh build --http-relative-path=/auth

I tried the below commands:
./kc.sh start-dev --http-port=8080 → New base path doesn’t take effect
./kc.sh start-dev --http-port=8080 --hostname-admin=/auth → it redirects to Page not found
./kc.sh start-dev --http-port=8080 --hostname-path=/auth → it redirects to blank page with errors on browser console
./kc.sh start-dev --http-port=8080 --hostname-path=/auth --hostname-admin=/auth → it redirects to blank page with errors on browser console

try putting --http-relative-path=/auth in your start-dev command. AFAIK, running build has no effect on running start-dev. It is only for use before start

It worked :+1:
thank you @xgp

Hi @xgp.

The --http-relative-path=/auth flag is not accepted in production mode.

Any idea ?

The build and start flags have to be used separately. If you look at the guide here Keycloak - Server - All configuration you will see a little tool icon next to --http-relative-path. That means you can either use it with build or start-dev. If you want your production setup to use --http-relative-path, you must first run it in build, and then start will use it.

My understanding is that the goal was to make startup time faster, but I’ve noticed here that how and where to use the configuration options is now a consistent source of confusion.

I understand the building process, before starting the application, no matter the mode I try to start, start-dev (development mode) or start (production mode) I always run kc.sh build --http-relative-path=/auth

I figured out the problem

I was running ./kc.sh start --hostname=www.mydomain.com --https-port=8181
It seems that for the frontend app the --https-port is ignored

After running:
./kc.sh start --hostname=www.mydomain.com:8181 --https-port=8181

Now everything is working properly when I try to access the Admin console.

Thanks for your help @xgp

1 Like

Careful when you move to 17.0.1 - that port number after the host name is not supported anymore (apparently it shouldn’t actually work in 17.0.0), so you’ll likely need to make adjustments. Test before upgrading!

Hi @soundsessential, yes it is working fine for me on version 17.0.0.

If get any problem when moving to 17.0.1 I get back here.

Thank you