Upgrade keycloak to 18.0.0 #18441
Upgrade keycloak to 18.0.0 #18441
Conversation
|
fixes: #17850 |
|
@DanielFran @vishal423 |
|
@yelhouti, I suggest trying failed workflows on local env to reproduce issues |
|
@vishal423 I could not reproduce locally, also they fail sporadically in the CI. This is why some ouath2 test pass and other fails. Is there a way to access cypress dashboard ? |
@vishal423 no what I am saying is the way keycloak starts changed (no way to have a port offset of 1000) https://github.com/jhipster/generator-jhipster/pull/18441/files#diff-1bfaf6e31fe218cd507027450c04913b93f510df3f63b4a2ea84163c6423e9fbL339 But we still want to offset ports to have docker and keycloak not fight for port 8080 on localhost so we map keycloak:8080 to localhost:9080 Also please give others the benefit of the doubt :) |
Got it. You are trying to access within the docker network. Failure tests seems related to micro-frontend and micro-services. Can you try those flows locally? |
|
I tried ms-angular locally which one would you recommend. Also --monolith and --worksoace doesn't seem to work correctly maybe I am doing something wrong I use scripts 11 and 12 the same way they are used on the workflow |
|
Can your please fix conflicts @yelhouti? |
|
I spent the last few hours understanding the issue with my PR and it is as follows: Since keycloak doesn't support port offset anymore we are "forced" to change the port mapping at the docker level.
Possible solution: What the you all think we should do about this ? @mraible @vishal423 echo "127.0.0.1 keycloak" | sudo tee -a /etc/hosts |
|
Can we convince Keycloak to add the port offset back in? Is there an issue
to track its removal?
…On Tue, May 17, 2022 at 07:40 yelhouti ***@***.***> wrote:
I spent the last few hours understanding the issue with my PR and it is as
follows:
Since keycloak doesn't support port offset anymore we are "forced" to
change the port mapping at the docker level.
The issue then becomes as follows:
Since our code uses the same issuer-uri to:
1. talk directly to the IDP (verify tokens...)
2. redirect the user for login
If we set it to:
3. keycloak:8080 the browser is unable to talk to it because it can't
resolve keycloak correctly (and pointing to localhost as I suspect we do
now doesn't solve the problem) as mentioned in docker-compose.yaml: # For
Keycloak to work, you need to add '127.0.0.1 keycloak' to your hosts file
(which is cheating and I don't know how github actions was configured to do
that
4. localhost:9080 the gateway is not able to talk to localhost
correctly because it is inside the container.
Possible solution:
The gateway should know 2 urls: 1 for internal use (to verify token,
retrieve oidc config in Security Configuration...) and one to return to the
frontend or redirect the frontend to.
There are other solutions I could think of but they are much more
complicated, change the used authentication flow, or don't work in some
edge cases...
What the you all think we should do about this ? @mraible
<https://github.com/mraible> @vishal423 <https://github.com/vishal423>
—
Reply to this email directly, view it on GitHub
<#18441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAELZDD23Q5SVBOER3IUM3VKNEM7ANCNFSM5UBGLBVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@mraible I don't think they should, the only reason our code was working is because we where using a "hack". I think its our code that needs fixing... Maybe there is a way to retrieve the IP of the keycloak container and make keycloak resolve to that instead of 127.0.0.1 which would be a correct way of doing this. |
|
@mraible 03-system.sh is the one pointing keycloak to 127.0.0.1 we could fix the ip of keycloak an change 03-system.sh. Or we could run a similar script once keycloak has started and the ip is read using docker container inspect | grep ... |
|
I agree the current requirement to edit your hosts file isn't ideal. However, it's only required when running everything with Docker or in CI. I've yet to figure out a better solution but would love to find one! |
|
As I mentioned, this can be achieved by specifying a different URL for server to server communication than the one used to redirect the user to... But for now what d you think I should do ?
|
|
Making the keycloak host dynamic will be a pain for development. Add |
|
@mshima this is a hack, I would rather configure a network in app.yaml and set the IP in the compose file to a fixed one, and tell people to add it to /etc*hosts. |
|
@mshima I understand what you mean, although the approach of changing ports is wrong, I think its easier to do for most people, so sadly I think I will switch back to it. |
yelhouti
force-pushed
the
keycloak-18
branch
3 times, most recently
from
e2835fb to
47d9bbd
Compare
|
I tested this today on my M1 and everything worked great. I have the following in my I tested with |
|
@mraible thanks a lot for you time :) |
|
@mshima I made the changes you requested for, could you check them please :) |
|
Thanks @yelhouti |
|
Many thanks @yelhouti for the huge work. |
|
@DanielFran of course I will in few, but they can safely be closed |
|
@mshima indeed thank you for your feedback :) goes to prove that correct doesn't always mean better |
|
claiming bounty :) https://opencollective.com/generator-jhipster/expenses/78206 (if no one minds) |
|
can #17850 be closed ? |
|
@DanielFran : thanks |
|
Thank you all :) |
DanielFran
changed the title
|
Can we make it so `docker-compose.yml` uses port 9080 like `keycloak.yml`
does?
That way, your way (grab the IP from Docker and add it to the hosts file)
and the current way both work.
…On Thu, May 19, 2022 at 09:37 yelhouti ***@***.***> wrote:
@yelhouti <https://github.com/yelhouti> Can you please explain why when I
run Keycloak for the gateway (with docker-compose -f
src/main/docker/keycloak.yml up -d), it can run on 9080. However, when I
run with Docker Compose (from the docker-compose folder), it needs to run
on 8080?
@mraible <https://github.com/mraible> Sure !
I understand why you think that they run in different ports but in reality
they don't. Here is what is happening:
docker run apps in a private network with it's own port management, dns
resolution... In that network the keycloak container has a dns entry
keycloak and an open port where the app runs on 8080.
All pods inside docker (in the same network, the default one when nothing
is specified) can talk to keycloak using the "url" keycloak:8080.
However your browser is running directly in the host, not inside docker
and therefor can not talk to keycloak, unless the port is exposed. We do
that by specifying 127.0.0.1:9080:8080 ie redirect all traffic coming to
127.0.0.1:9080 to this container's (keycloak) 8080 and now keycloak can
be reached on 127.0.0.1:9080 .
But since in your /etc/hosts you have forced keycloak to resolve to
127.0.0.1 your browser can reach keycloak on keycloak:9080.
Why is using keycloak.yml and docker-compose.yml different.
When using keycloak.yml everything expect keycloak is running on the host,
and keycloak is exposed for all component on 127.0.0.1:9080 So everything
work great.
However, when using docker-compose.yml everything *expect the browser* is
running inside the private network and they can talk to it using:
keycloak:8080. But the browser doesn't know how to resolve keycloak so it
fails. To fix the browser, we just need to tell our machine where to
resolve keycloak and everything should work great. How we so that is just
by changing /etc/hosts <PRIAVTE_KEYCLOAK_IP> keycloak and we can reach it
in the private network ip and port 8080. Of course we can still reach it in
this case too on 127.0.0.1:9080 if it is exposed, or we can just choose
not to expose it on a different port.
Finally keycloak:9080 should never work unless you still have the old 127.0.0.1
keycloak in your /etc/hosts file.
—
Reply to this email directly, view it on GitHub
<#18441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAELZAOLDY6M5CFO5QLZWTVKYDWFANCNFSM5UBGLBVQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@mraible what is the exact change you are proposing please ? doesn't docker-compose.yml already use 9080 ? |
|
@yelhouti No changes need to be made as far as I know. When I made the comment above, it was using a different port. |
Please make sure the below checklist is followed for Pull Requests.
When you are still working on the PR, consider converting it to Draft (below reviewers) and adding
skip-cilabel, you can still see CI build result at your branch.