Hi guys, I have configured the keycloak angular example <https://github.com/keycloak/keycloak/tree/master/examples/ demo-template/angular-product-app> to utilise a production grade setup Keycloak server and the example ends up in an endless redirect loop. I can see that the Keycloak server POST response in the authorization code exchange contains 2 identical Access-Control-Allow-Credentials headers, which the Chrome browser cannot understand and then subsequently fails the XHR request. I included the full HTTP trace below for reference. Keycloak server is 1.9.8 (RH SSO 7.0.0) and I tried 1.9.8 and 2.2.1 Keycloak JavaScript clients but given the browsers refuse to accept the server response headers the client is pretty much irrelevant. Did anyone of you ever came across this issue? Cheers, Niels *Request* URL: https://sso.server.com/auth/realms/[redacted]/protocol/ openid-connect/token Request Method:POST Status Code:200 OK Remote Address:[redacted]:8080 *Request Headers* POST /auth/realms/[redacted]/protocol/openid-connect/token HTTP/1.1 Host: sso.server.com Connection: keep-alive Content-Length: 205 Pragma: no-cache Cache-Control: no-cache Origin: http://localhost:8080 User-Agent: Mozilla/5.0 (iPad; CPU OS 9_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 Safari/601.1 Content-type: application/x-www-form-urlencoded Accept: */* Referer: http://localhost:8080/angular-product/ Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.8,de;q=0.6 Cookie: KEYCLOAK_STATE_CHECKER=[redacted];KC_RESTART=[ redacted];KEYCLOAK_IDENTITY=[redacted];KEYCLOAK_SESSION=[redacted] *Form Data* code=[redacted]&grant_type=authorization_code&client_id= example-spa-app&redirect_uri=http%3A%2F%2Flocalhost%3A8080% 2Fangular-product%2F *Response Headers* HTTP/1.1 200 OK Date: Mon, 17 Oct 2016 06:13:24 GMT *Access-Control-Allow-Credentials: true <-- Chrome cannot understand this* *Access-Control-Allow-Credentials: true** <-- Chrome cannot understand this* Access-Control-Allow-Origin: http://localhost:8080 Access-Control-Expose-Headers: Access-Control-Allow-Methods Content-Type: application/json Content-Length: 3795 Keep-Alive: timeout=5, max=97 Connection: Keep-Alive _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Stian, yes the kc server was setup with an apache reverse proxy in front of it. After I could not replicate the problem in comparable vagrant build I took the test server appart and discovered that some smart cookie added a "Header always set Access-Control-Allow-Credentials true" to the apache reverse proxy configuration, which obviously will double up with what kc server returns. The devs had issues with a custom jQuery implementation of "sso session exists" check ( ... yes the one already implemented in the keycloak.js adapter ... ). Really sorry I wasted everyones time. On Tue, Oct 18, 2016 at 4:52 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > That's really strange. I can't see how Keycloak would add the header > twice. > > By production grade what do you mean? Is there any changes you could have > made that affects this? Is there a proxy in front of Keycloak that could > affect it? > > On 17 October 2016 at 12:30, Niels Bertram <nielsbne(a)gmail.com&gt; wrote: > >> Hi guys, >> >> I have configured the keycloak angular example >> <https://github.com/keycloak/keycloak/tree/master/examples/d >> emo-template/angular-product-app> >> to utilise a production grade setup Keycloak server and the example ends >> up >> in an endless redirect loop. >> >> I can see that the Keycloak server POST response in the authorization >> code >> exchange contains 2 identical Access-Control-Allow-Credentials headers, >> which the Chrome browser cannot understand and then subsequently fails >> the >> XHR request. I included the full HTTP trace below for reference. >> >> Keycloak server is 1.9.8 (RH SSO 7.0.0) and I tried 1.9.8 and 2.2.1 >> Keycloak JavaScript clients but given the browsers refuse to accept the >> server response headers the client is pretty much irrelevant. >> >> Did anyone of you ever came across this issue? >> >> Cheers, >> Niels >> >> >> >> *Request* >> URL: >> https://sso.server.com/auth/realms/[redacted]/protocol/openi >> d-connect/token >> Request Method:POST >> Status Code:200 OK >> Remote Address:[redacted]:8080 >> >> *Request Headers* >> POST /auth/realms/[redacted]/protocol/openid-connect/token HTTP/1.1 >> Host: sso.server.com >> Connection: keep-alive >> Content-Length: 205 >> Pragma: no-cache >> Cache-Control: no-cache >> Origin: http://localhost:8080 >> User-Agent: Mozilla/5.0 (iPad; CPU OS 9_1 like Mac OS X) >> AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13B143 >> Safari/601.1 >> Content-type: application/x-www-form-urlencoded >> Accept: */* >> Referer: http://localhost:8080/angular-product/ >> Accept-Encoding: gzip, deflate, br >> Accept-Language: en-US,en;q=0.8,de;q=0.6 >> Cookie: >> KEYCLOAK_STATE_CHECKER=[redacted];KC_RESTART=[redacted];KEYC >> LOAK_IDENTITY=[redacted];KEYCLOAK_SESSION=[redacted] >> >> *Form Data* >> code=[redacted]&grant_type=authorization_code&client_id=exam >> ple-spa-app&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fang >> ular-product%2F >> >> *Response Headers* >> HTTP/1.1 200 OK >> Date: Mon, 17 Oct 2016 06:13:24 GMT >> *Access-Control-Allow-Credentials: true <-- Chrome cannot understand >> this* >> *Access-Control-Allow-Credentials: true** <-- Chrome cannot understand >> this* >> Access-Control-Allow-Origin: http://localhost:8080 >> Access-Control-Expose-Headers: Access-Control-Allow-Methods >> Content-Type: application/json >> Content-Length: 3795 >> Keep-Alive: timeout=5, max=97 >> Connection: Keep-Alive >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >