We have a requirement to add the Cache-Control: no-store, no-cache
header to the logout
resource?
What is the best way to achieve this?
Can I re-implement/extend the logout
resource?
We have a requirement to add the Cache-Control: no-store, no-cache
header to the logout
resource?
What is the best way to achieve this?
Can I re-implement/extend the logout
resource?
The built-in OIDC endpoints are not part of an SPI implementation, and can’t be overridden.
Thanks for the response.
I have never tried it, but you may be able to add a header from another extension by
session.getContext().getUri()
session.getContext().getHttpResponse()
which has a setHeader
method, documented here HttpResponse (Keycloak Docs Distribution 26.1.4 API)Perhaps another option would be to add the desired header value on the reverse-proxy level, when processing the response(s) from Keycloak!?
why not change the core code and recompile keycloak? @dasniko isn’t that a valid solution? because I recall 4 years ago that the email section didn’t serve my needs, so i changed the code and recompiled the jars and deployed it to wildfly.
Sorry to say, I think that’s the worst possible solution. Forking keycloak core means you have to maintain your changes with every version release. Even with the slower pace of major releases, that’s a lot of work to make sure you are maintaining and testing it properly.
I think @dasniko 's solution is the most elegant, as you can do it without changing anything in Keycloak or in an extension.
I did a test on my suggested solution, and it works properly. If you are already building an extension for other reasons, it’s a valid solution that doesn’t require forking keycloak core.
Nothing to here for @xgp s comment.
Not just because something is technically possible, it is a good solution.
No problem guys, I appreciate your thoughts and answers, thank you!
Why not adding its own logout endpoint with your logic?
As an alternative, you can deploy a simple JAX-RS filter into Keycloak. This example does exactly what you’re looking for, but for UserInfo endpoint (you will need to change that to LogoutEndpoint).
Pros:
Cons:
Good luck!
Thank you. This is what we are doing at the moment. I was just hoping for a solution closer to the service.
This looks good. I will give it a try. Thank you!