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

[Stian Thorgersen]

Np, pleased it's sorted

On 19 October 2016 at 07:26, Niels Bertram <nielsbne at gmail.com> wrote:

> 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 at 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 at 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];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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>