12:26 a.m.
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>
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> 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];
> KEYCLOAK_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
>