Prevent Cloudflare from automatically folding set-cookie headers

We are running an applicated called keycloak whose traffic is proxied via Cloudflare. Starting today we found that users on Chromium based products (Chrome, Edge etc) were unable to login, this did not effect Firefox and Safari users. We managed to track this down to what we think is Cloudflare mangling the set-cookie response to chrome, i have listed two example payloads when cloudflare is on vs off. When on the cookies are not set and the application fails

set-cookie: AUTH_SESSION_ID=d637d240-500b-49e3-8691-74b53d98c8f5.ae2d4b6f8713; Version=1; Path=/auth/realms/testing/; SameSite=None; Secure; HttpOnly, AUTH_SESSION_ID_LEGACY=d637d240-500b-49e3-8691-74b53d98c8f5.ae2d4b6f8713; Version=1; Path=/auth/realms/testing/; Secure; HttpOnly, KEYCLOAK_IDENTITY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure; HttpOnly, KEYCLOAK_IDENTITY_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure; HttpOnly, KEYCLOAK_SESSION=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure, KEYCLOAK_SESSION_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure, KEYCLOAK_IDENTITY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure; HttpOnly, KEYCLOAK_IDENTITY_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure; HttpOnly, KEYCLOAK_SESSION=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure, KEYCLOAK_SESSION_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure

vs without cloudflare

set-cookie: AUTH_SESSION_ID=f1468edf-f50d-4277-962b-c1bf3218ecb6.1d35433e1005; Version=1; Path=/auth/realms/testing/; SameSite=None; Secure; HttpOnly
set-cookie: AUTH_SESSION_ID_LEGACY=f1468edf-f50d-4277-962b-c1bf3218ecb6.1d35433e1005; Version=1; Path=/auth/realms/testing/; Secure; HttpOnly
set-cookie: KEYCLOAK_IDENTITY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure; HttpOnly
set-cookie: KEYCLOAK_IDENTITY_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure; HttpOnly
set-cookie: KEYCLOAK_SESSION=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure
set-cookie: KEYCLOAK_SESSION_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing/; Secure
set-cookie: KEYCLOAK_IDENTITY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure; HttpOnly
set-cookie: KEYCLOAK_IDENTITY_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure; HttpOnly
set-cookie: KEYCLOAK_SESSION=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure
set-cookie: KEYCLOAK_SESSION_LEGACY=; Version=1; Comment=Expiring cookie; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Max-Age=0; Path=/auth/realms/testing; Secure

Has anyone else experienced any related issues, or is there anyway we can see if anything has changed in cloudflare that would cause this issue.

2 Likes

I believe this issue is related to the one someone else also logged today, any clarity on this would be appreciated

1 Like

Encountered the same problem, have a great impact on our service

2 Likes

We are facing the same issue, does anyone know of a workaround for this until an official answer comes?

2 Likes

same issue here. it is very disrupting for our application.

1 Like

We’re experiencing the same issue but have had silence from Cloudflare support.

https://community.cloudflare.com/t/400-errors-only-when-orange-cloud-on/304970/3

1 Like

We issue the same problem, please fix this.

1 Like

I think this is related:

3 Likes

Yes, looks like the same issue - thanks for pointing it out!

2 Likes

Apparently this is caused by chome’s accept header:
text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9

Specifically the application/signed-exchange;v=b3;q=0.9 part, removing it from the accept header returns the cookie back to normal

1 Like

Hi,
Can you tell me how to remove these headers? Thanks

Hi. One quick solution that worked for us was disabling Display your site’s actual URL on your AMP pages, instead of the traditional Google AMP cache URL. from Mobile, under Speed/Optimization.

Also purged cache after.

Hope this helps.

1 Like

Hi,
I tested and it works. thanks so much

1 Like

Hi there, we’re currently investigating this issue on our end and will follow up on the respective tickets once we know more.

2 Likes

Similar problem here. Experiencing a majority of our customer base not being able to login or stay logged in due to a malformed session id cookie. Only solution for us was to disable cloudflare all together since we cannot afford this much loss of revenue.

1 Like

Hi all,

Just a quick update. Appears there is an issue with specific Set-Cookie headers:

We have a number of engineers investigating now. Please follow the incident link above for more updates.

Best,
Sam

4 Likes

Still experiencing this issue even if it should be resolved.

Since yesterday evening our customers can not register, login or order because Anto Forgery Token gets not set correctly to cookie store in Chromium-based browsers.

When can we expect the final solution for this case? Urgent!

Meanwhile after purging all cache, the issue is resolved for us too.

2 Likes

Is is possible to get an indication of when / what change caused this issue? I need to create an incident report for several customers who were unable to access their system and need to include a rough indication of when this issue started

@michael.connolly1 Issue started at 13th September around 18.00 CEST for us if this helps you. As this affected every login, registration, and form submission in our case, this is a near exact date, I think.

1 Like