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

[Niels Bertram]

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