Re: [keycloak-user] Keycloak angular SPA example does not work against an external Keycloak server - browser reject server response XHR

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 >> > >