#KeyCloak can not open Admin-Web-UI with the new V2 Runtime

34 messages · Page 1 of 1 (latest)

clever kelp
#

Hello everyone,

When I updated the runtime of my KeyCloak instance to the new Runtime V2, I noticed that I could no longer access the Admin Web UI. It gets stuck at the loading circle "Loading the Admin UI". I didn't notice anything suspicious in the KeyCloak logs.

In the network console you can see that a call is leading to a 403.
(I don't know how this could be related to the runtime)

The user management UI doesn't work either (where users can manage their own information)

I get a message saying "failed to initialize keycloak"

(You can also see the 403 here in the network console)

My Dockerfile uses the same multi-run logic as here:

https://github.com/leonardochappuis/keycloak-docker/blob/master/Dockerfile

I hope someone knows what the cause is, because in the future
the V2 runtime is set.

Thanks in advance for your time

serene raptorBOT
#

Project ID: f751037a-ba7a-42ab-8a24-90e99fcd12d3

clever kelp
#

f751037a-ba7a-42ab-8a24-90e99fcd12d3

clever kelp
#

I have now updated KeyCloak to the latest version, namely version 25.0.1.

Now I get a different error message:
"HTTPS required"
The logs say:
error="ssl_required"

This error only appears in the V2 runtime.
Has anything changed regarding SSL processing in the V2 runtime?

vestal yarrow
#

interesting, I will look into it later today

clever kelp
clever kelp
#

The new edge Proxy-Feature also did not make a difference

clever kelp
#

i think, i found the solution. I will test it a little more and post it than here

clever kelp
#

OK, I've now made a small step forward:
If I set the KeyCloak parameter "Proxy Headers" to "forwarded" and no longer to "xforwarded" then at least the login page is displayed correctly again.
The login still doesn't work and I can't access the admin UI either.

Does the new runtime use new proxy headers?

clever kelp
#

Another new finding:
When redirecting from KeyCloak to my application,
the KeyCloak server is specified in the "iss" parameter in the URL.
The legacy runtime uses https.
The V2 runtime uses http.
This reinforces my suspicion that
the behavior regarding the forward headers has changed

vestal yarrow
#

the runtime and the edge proxy are separate systems, the runtime would have nothing to do with headers

clever kelp
#

OK, then the behavior surprises me even more.
I'll try to get the Caddy proxy to log the incoming HTTP headers to check
whether the forwarded headers change in any way

vestal yarrow
clever kelp
vestal yarrow
#

for what it's worth, I was able to reproduce the issue you described with a fresh template deploy, but I got it to work and was able to login after making the changes that I submitted in that PR

clever kelp
#

That's good to hear (:
I'm curious what causes these errors in the new runtime, but it's not worth going into the analysis if the PR fixes the problem

vestal yarrow
#

not sure the runtime is at fault here, we can't jump to such conclusions

#

jumping to conclusions like that has bit me in the past

clever kelp
#

It works now! Thanks for your support Brody!
Bought you some coffees ☕

vestal yarrow
#

thank you very much! I appreciate that

clever kelp
#

how can i mark your answer as the solution?

uncut hearthBOT
vestal yarrow
#

only mods/admins can

clever kelp
#

ahh, that explains it (:

vestal yarrow
#

update, my pr was merged and the template was updated!

marsh violet
#

Hello. I did not understand what was I supposed to do but just deployed this app I am not able to display the login page for some reason. It just tries to open and then giving this screen:

#

What is the problem you think? Thank you in advance!

vestal yarrow
#

change KC_HOSTNAME="${{RAILWAY_PUBLIC_DOMAIN}}" to KC_HOSTNAME="https://${{RAILWAY_PUBLIC_DOMAIN}}"

#

@clever kelp - can you update this on the template for future users?

marsh violet
#

Thank you!

clever kelp