Repository navigation
Non-secure context detected; cookies are not secured, and will not be available in cross-origin POST requests #36094
Replies: 9 comments 27 replies
This was also brought up on #35160. There isn't currently a straight-forward way to do this. The current workaround without actually using HTTPS would be to use proxy headers such has x-forwarded-proto=https from your backend. Of course that means setting up the server proxy-headers variable and ensuring that only backend and actual proxies can actually communicate with Keycloak. There is a related feature on realms called ssl required which is based upon checking if a local network was used to make a request. If something like that were configurable to your docker network and consulted for the secure context check, then it would work as you expect - but this may not be the direction we actually want to go. Any additional thoughs @vmuzikar @jonkoops @stianst ? |
|
There is no way to fix this simply because this is enforced by the user-agent (browser). Keycloak attempts to set cookies in a way that will be most compatible, but we eventually are limited by what the user-agent allows. |
|
@stere-marius Could you please elaborate a bit on your specific use case? Especially why does your backend use cookies? Cookies are usually used only on the frontend endpoints and there we could easily detect the actual protocol (whether it's HTTPS on the front even when the communication with the proxy is over HTTP – TLS edge termination) from the Hostname Provider, so we could easily enough not log the warning in these cases. |
|
Same issue here. EDIT: |
|
@MR4online this discussion is for http access to Keycloak under two scenarios - either when there is an edge proxy and http access is coming not from the proxy, or possibly there's only http access If you have a cookie warning or seem to be failing cors checks when going through a proxy, then that means your keycloak proxy settings are incorrect. Please check your proxy-headers setting and ensure that the proxy is setting the appropriate headers.
Generally you don't want to do that. |
|
@stere-marius re-reading your discription are you in an http only deployment? That is the only access to keycloak is over http via the docker network? |
|
I stumbled over similar errors: I am attempting to deploy docker these cookie warnings seem non-fatal so far, but I am performing upgrades from |
|
I get the same warning. I use Keycloak behind a reverse proxy (local docker environment) with an self signed SSL cert. From the user view, everything works like expected. No Cookie warning is present. In my application I also use several requests to REST Admin API in a non secure context. This means, I send a request from my app to Keycloak via http://host.docker.internal over port 80 direct to Keycloak without using the reverse proxy. My REST API requests are plain PHP, over Guzzle which use curl in the end. The implementation didn't use cookies and the request didn't ask for it. For authentication my REST API client use the Bearer-Token. Keycloak is configured in this way:
The non secure context is no problem for me, I secure the communication between the services by my own. Of course, I can connect the API requests over the reverse proxy, this works and in this way there are no cookie warnings. But I would prefer a direct communication between the service containers. |
The server is trying to set a cookie, that is triggering the warning. |
|
So, for this scenario, the only way for me to handle it is to actually have my Keycloak responding over HTTPS, having to deal with self-signed certificates (since the cost of a certificate from an official CA wouldn’t make sense)? |
|
Is the problem that you are seeing a warning, or is something not working for you? |
|
At first, everything is indeed working fine; the concern with the warning is that it’s affecting some monitoring. Is there any way I can disable this warning? Or perhaps some configuration I can set so that Keycloak doesn’t try to inject a cookie in the response, and therefore doesn’t fall into this scenario? |
|
You do have control over the log level for a given context, but you should probably look first at the flow for this authentication and see why it's setting a cookie. |
|
Hey. I am getting the same error. I have keycloak and Caddy (reverse proxy) in docker environment on VM-B. I set up Caddy to make internal domain (keycloak.internal.my-domain.com) and forward the requests to keycloak-keycloak-1 container on port 8080 (Caddy and Keycloak has common docker network "proxy"). And every time i log in, it would throw this error / warning. When i want to publish the service (like shown in the answer here) under keycloak.my-domain.com, it wouldn't even let me log in. After i enter credentials, it would hang on the loading circle and write these errors a couple of times. Where could be the issue? PS: the in-depth description of my setup is in the link where i mentioned the answer. |
|
At least the warning should be suppressed, but IMHO different deployments may face different challenges. We are using ISTIO TLS termination, and so far I only see the issue with logs being flooded with that error message. That said, assuming that environment is unsecure without the possibility to tell (override) Keycloak that actually we are in secure environment seems to be not correct. From my POV this is a regression in current version 26.1.3 in comparison to version 25.0.6 (the current version we are working with). As a minimum the code should respect x-forwarded-proto=https |
As mentioned here #36094 (reply in thread) it does - please check your proxy-headers setting. |
|
And what about scenario if everything is http, the warning can not be and should not be avoided then, obviously? |
|
It may help to clarify if you mean an edge proxy scenario or just using keycloak directly over http. Either way we aren't checking to see if only have http enabled as a pre-condition for this warning. If you however use a localhost host over http, then there will be no warning. |
|
sorry not to be precise enough. |
Uh oh!
There was an error while loading. Please reload this page.
Hello,
I'm trying to resolve a warning related to Keycloak communicating with my backend over HTTP. Keycloak and my backend are on the same Docker network, and every time my backend communicates with Keycloak, we encounter the following warning:
[org.keycloak.cookie.DefaultCookieProvider] (executor-thread-12) Non-secure context detected; cookies are not secured, and will not be available in cross-origin POST requestsThe issue stems from the fact that we are using HTTP to communicate with the Keycloak service within this Docker network. Specifically, I use http://keycloak:8080/auth to communicate with the Keycloak service.
Is there a way to resolve this issue without switching to HTTPS for internal communication between services?
Thank you!
All reactions