Repository navigation
Replies: 3 comments 4 replies
|
Hi @gjain-sag , thanks for raising this discussion! The You will be still able to set it in a few ways, but I do believe that we should avoid supporting compatibility layers whenever possible. Maybe I'm missing something, would you like to share the reasons why it's hard for you to remove the relative path? cc. @pedroigor @vmuzikar |
|
@gjain-sag Thank you for raising this topic! Even though we don't support direct migration from WF dist (and the old Operator) to Quarkus dist (and the new Operator), I believe it is still a valid use case to have the possibility to use Created #12100. |
|
Before tackling this Issue I would like to hear more opinions on this one, I believe that @pedroigor and I are more inclined to drop the support instead. |
|
Thanks @andreaTP , We have many dependent applications which are using our client for authentication and other configurations. Removing support for "/auth" will create backward compatibility issues for us. |
|
In our case we have one reverse proxy TLS endpoint for one public sub domain, serving all calls to different backends based of url path. Removing At the end it's just more PKI and system maintainance for nothing. |
|
Same for us. Removing the /auth path would require us to adapt all our reverse-proxies configurations and update some of our apps. |
|
Looks like it should be there for a while but we should have a deadline for removing it. @stianst wdyt? |
Uh oh!
There was an error while loading. Please reload this page.
Hi Team,
As per our current Keycloak architecture we have a dependency on "/auth" relative path. I tried to retain the same via configuration "http-relative-path=/auth", once the cluster is up liveness and readiness fails with url " http://127.0.0.1:8080/health/live" configured.
Do we have any way to update the Liveness and Readiness configurations in the cluster based on http-relative-path??
All reactions