Can't log in to clients on 26.0.5 #34803

oculos · 2024-11-10T08:50:12Z

oculos
Nov 10, 2024

Before reporting an issue

I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.

Area

authentication

Describe the bug

I suddenly can't login to my clients after updating to 26.0.5

I am not sure what happened. I enter my username and password, but I don't get presented with the two-factor.

All I get in the logs is this:

Non-secure context detected; cookies are not secured, and will not be available in cross-origin POST requests

Version

26.0.5

Regression

The issue is a regression

Expected behavior

To log in properly

Actual behavior

I don't get logged in. I end up with a timeout and gateway error

How to Reproduce?

Upgrade to 26.0.5

Anything else?

No response

shawkins · 2024-11-10T13:10:05Z

shawkins
Nov 10, 2024
Collaborator

Non-secure context detected; cookies are not secured, and will not be available in cross-origin POST requests

Are you running an edge / tls terminiation proxy? If so there is now a check for a secure context that will require you to have enabled proxy-headers and are setting at least a header that would convey the scheme.

Relates to #34780

0 replies

oculos · 2024-11-10T15:48:31Z

oculos
Nov 10, 2024
Author

Thanks. Actually my problem was DNS.

But I still keep getting this errors. I do have proxy edge termination, and I have the headers configured:

On my nginx:

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;

And on my ingress:

      nginx.ingress.kubernetes.io/configuration-snippet: |
        more_set_headers "X-Forwarded-For $http_x_forwarded_for";
        proxy_set_header X-Forwarded-Proto: https;

My Dockerfile has this:

ENV KC_PROXY_HEADERS=xforwarded
ENV KC_PROXY_TRUSTED_ADDRESSES=10.20.30.10,10.234.0.0/8,127.0.0.0/8
#ENV KC_PROXY=edge
ENTRYPOINT ["/opt/keycloak/bin/kc.sh"]

My deployment yml:

 additionalOptions:
    - name: proxy-headers
      value: xforwarded
    - name: proxy-trusted-addresses
      value: "10.20.30.15,10.234.0.0/16"
#    - name: proxy
#      value: edge
#   - name: hostname-debug
 #     value: "true"

Should I do something differently?

0 replies

shawkins · 2024-11-10T18:03:07Z

shawkins
Nov 10, 2024
Collaborator

But I still keep getting this errors.

Yes, that's still indicative of a proxy configuration issue.

Should I do something differently?

It looks like you have an nginx proxy in front of the ingress proxy. If you are going through the ingress, those pods would need to be in the proxy-trusted-addresses.

You are also showing two different configurations for proxy-trusted-addresses. Both end up as env properties, I would presume that the one from the deployment should take effect. You may want to review that just in case.

0 replies

jonkoops · 2024-11-10T18:24:00Z

jonkoops
Nov 10, 2024

Moving this to a discussion as it is likely a configuration issue and not a bug.

0 replies

oculos · 2024-11-10T18:24:08Z

oculos
Nov 10, 2024
Author

But I still keep getting this errors.

Yes, that's still indicative of a proxy configuration issue.

Should I do something differently?

It looks like you have an nginx proxy in front of the ingress proxy. If you are going through the ingress, those pods would need to be in the proxy-trusted-addresses.

You are also showing two different configurations for proxy-trusted-addresses. Both end up as env properties, I would presume that the one from the deployment should take effect. You may want to review that just in case.

Sorry, I just copied the wrong ip's, but they are the same. The only difference is that on the deployment there's no 127.0.0.1/24.

0 replies

shawkins · 2024-11-11T12:22:35Z

shawkins
Nov 11, 2024
Collaborator

Unfortunately I don't think there's any logging on the effect of the trusted proxy setting, but it's quite possible that the ingress pods don't have stable ips. Can you test without the trusted proxies set? The only other thing you can verify is that requests hitting the server have the expected headers.

1 reply

oculos Nov 13, 2024
Author

I added the full ip range of my cluster, so I don't think that's the problem.
But, adding the legacy proxy: edge back fixed it, apparently.

jaapspiering · 2025-06-04T14:29:54Z

jaapspiering
Jun 4, 2025

I was seeing the behaviour described in #31377 combined with the logging described here. In my case the cause was a missing KC_PROXY_HEADERS=xforwarded environment variable.

0 replies

Navigation Menu

Repository navigation

Can't log in to clients on 26.0.5 #34803

Uh oh!

{{title}}

Uh oh!

Replies: 7 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Can't log in to clients on 26.0.5 #34803

Uh oh!

oculos Nov 10, 2024

Before reporting an issue

Area

Describe the bug

Version

Regression

Expected behavior

Actual behavior

How to Reproduce?

Anything else?

Replies: 7 comments · 1 reply

Uh oh!

Uh oh!

shawkins Nov 10, 2024 Collaborator

Uh oh!

oculos Nov 10, 2024 Author

Uh oh!

shawkins Nov 10, 2024 Collaborator

Uh oh!

jonkoops Nov 10, 2024

Uh oh!

oculos Nov 10, 2024 Author

Uh oh!

shawkins Nov 11, 2024 Collaborator

Uh oh!

oculos Nov 13, 2024 Author

Uh oh!

jaapspiering Jun 4, 2025

oculos
Nov 10, 2024

Replies: 7 comments 1 reply

shawkins
Nov 10, 2024
Collaborator

oculos
Nov 10, 2024
Author

shawkins
Nov 10, 2024
Collaborator

jonkoops
Nov 10, 2024

oculos
Nov 10, 2024
Author

shawkins
Nov 11, 2024
Collaborator

oculos Nov 13, 2024
Author

jaapspiering
Jun 4, 2025