8:04 a.m.
Hi all,
I'm building a new app using GWT 2.7 using the Keycloak javascript adapter
and GWT jsInterop. This works extremely well.
The problem I ran into is if I walk away for 5 minutes and then try to do
something, the token refresh fails on preflight. As shown in the
documentation, I call keycloak.updateToken(30) to refresh the base token in
case it has expired. Since in this case it has indeed expired, keycloak
makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call
to this location doesn't contain the Accept headers, and my app ends up
dead in the water.
To fix this, I added the following code to OpenIDConnectService:
/**
* CORS preflight path for refresh token requests
*
* @return
*/
@Path("refresh")
@OPTIONS
@Produces(MediaType.APPLICATION_JSON)
public Response refreshAccessTokenPreflight() {
if (logger.isDebugEnabled()) {
logger.debugv("cors request from: {0}",
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
}
return Cors.add(request, Response.ok()).auth().preflight().build();
}
If this wasn't the correct solution for my problem, I'd enjoy hearing where
I went wrong.
Thanks,
Alain
8:32 a.m.
It's the correct approach to add the preflight. Please send a PR and we'll merge
it.
Out of curiosity do you know why it's sending a preflight in your app? It doesn't
when I test it out here, which AFAIK is correct according to spec (content-type is
application/x-www-form-urlencoded and there's no custom headers set).
----- Original Message -----
From: "Alain Penders" <alain(a)rexorient.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 3:04:50 PM
Subject: [keycloak-dev] Fwd: Preflight for token refresh
Hi all,
I'm building a new app using GWT 2.7 using the Keycloak javascript adapter
and GWT jsInterop. This works extremely well.
The problem I ran into is if I walk away for 5 minutes and then try to do
something, the token refresh fails on preflight. As shown in the
documentation, I call keycloak.updateToken(30) to refresh the base token in
case it has expired. Since in this case it has indeed expired, keycloak
makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call to
this location doesn't contain the Accept headers, and my app ends up dead in
the water.
To fix this, I added the following code to OpenIDConnectService:
/**
* CORS preflight path for refresh token requests
*
* @return
*/
@Path("refresh")
@OPTIONS
@Produces(MediaType.APPLICATION_JSON)
public Response refreshAccessTokenPreflight() {
if (logger.isDebugEnabled()) {
logger.debugv("cors request from: {0}",
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
}
return Cors.add(request, Response.ok()).auth().preflight().build();
}
If this wasn't the correct solution for my problem, I'd enjoy hearing where I
went wrong.
Thanks,
Alain
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:43 a.m.
I'm testing my UI using GWTs Super Dev Mode, which means its origin is set
to http://127.0.0.1:8888. Keycloak runs on http://127.0.0.1:8080/auth.
On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
It's the correct approach to add the preflight. Please send a PR
and we'll
merge it.
Out of curiosity do you know why it's sending a preflight in your app? It
doesn't when I test it out here, which AFAIK is correct according to spec
(content-type is application/x-www-form-urlencoded and there's no custom
headers set).
----- Original Message -----
> From: "Alain Penders" <alain(a)rexorient.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 2 December, 2014 3:04:50 PM
> Subject: [keycloak-dev] Fwd: Preflight for token refresh
>
> Hi all,
>
> I'm building a new app using GWT 2.7 using the Keycloak javascript
adapter
> and GWT jsInterop. This works extremely well.
>
> The problem I ran into is if I walk away for 5 minutes and then try to do
> something, the token refresh fails on preflight. As shown in the
> documentation, I call keycloak.updateToken(30) to refresh the base token
in
> case it has expired. Since in this case it has indeed expired, keycloak
> makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call
to
> this location doesn't contain the Accept headers, and my app ends up
dead in
> the water.
>
> To fix this, I added the following code to OpenIDConnectService:
>
> /**
> * CORS preflight path for refresh token requests
> *
> * @return
> */
> @Path("refresh")
> @OPTIONS
> @Produces(MediaType.APPLICATION_JSON)
> public Response refreshAccessTokenPreflight() {
> if (logger.isDebugEnabled()) {
> logger.debugv("cors request from: {0}",
> request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> }
> return Cors.add(request, Response.ok()).auth().preflight().build();
> }
>
> If this wasn't the correct solution for my problem, I'd enjoy hearing
where I
> went wrong.
>
> Thanks,
> Alain
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:49 a.m.
----- Original Message -----
From: "Alain Penders" <alain(a)rexorient.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 3:43:13 PM
Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
I'm testing my UI using GWTs Super Dev Mode, which means its origin is set
to http://127.0.0.1:8888. Keycloak runs on http://127.0.0.1:8080/auth.
Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT request. My guess
is that "GWTs Super Dev Mode" sets some custom headers on all requests.
On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
> It's the correct approach to add the preflight. Please send a PR and we'll
> merge it.
>
> Out of curiosity do you know why it's sending a preflight in your app? It
> doesn't when I test it out here, which AFAIK is correct according to spec
> (content-type is application/x-www-form-urlencoded and there's no custom
> headers set).
>
> ----- Original Message -----
> > From: "Alain Penders" <alain(a)rexorient.com>
> > To: keycloak-dev(a)lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> >
> > Hi all,
> >
> > I'm building a new app using GWT 2.7 using the Keycloak javascript
> adapter
> > and GWT jsInterop. This works extremely well.
> >
> > The problem I ran into is if I walk away for 5 minutes and then try to do
> > something, the token refresh fails on preflight. As shown in the
> > documentation, I call keycloak.updateToken(30) to refresh the base token
> in
> > case it has expired. Since in this case it has indeed expired, keycloak
> > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS call
> to
> > this location doesn't contain the Accept headers, and my app ends up
> dead in
> > the water.
> >
> > To fix this, I added the following code to OpenIDConnectService:
> >
> > /**
> > * CORS preflight path for refresh token requests
> > *
> > * @return
> > */
> > @Path("refresh")
> > @OPTIONS
> > @Produces(MediaType.APPLICATION_JSON)
> > public Response refreshAccessTokenPreflight() {
> > if (logger.isDebugEnabled()) {
> > logger.debugv("cors request from: {0}",
> > request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > }
> > return Cors.add(request, Response.ok()).auth().preflight().build();
> > }
> >
> > If this wasn't the correct solution for my problem, I'd enjoy hearing
> where I
> > went wrong.
> >
> > Thanks,
> > Alain
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
9:02 a.m.
Not really. It needs CORS for every URI it hits. Refresh is a different
URI from the code->token exchange one it uses initially.
When Keycloak redirects back to the GWT app and the code is exchanged for
the tokens, I see this in the Network trace:
First an OPTIONS request:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
3. Request Method:
OPTIONS
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate, sdch
3. Accept-Language:
en-US,en;q=0.8
4. Access-Control-Request-Headers:
authorization, content-type
5. Access-Control-Request-Method:
POST
6. Connection:
keep-alive
7. Host:
localhost:8080
8. Origin:
http://127.0.0.1:8888
9. Referer:
http://127.0.0.1:8888/Main.html
10. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
GET, HEAD, OPTIONS
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Max-Age:
3600
6. Connection:
keep-alive
7. Content-Length:
0
8. Date:
Tue, 02 Dec 2014 14:51:47 GMT
9. Server:
WildFly/8
10. X-Powered-By:
Undertow/1
Then the actual code exchange request:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
3. Request Method:
POST
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate
3. Accept-Language:
en-US,en;q=0.8
4. Authorization:
Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
5. Connection:
keep-alive
6. Content-Length:
85
7. Content-type:
application/x-www-form-urlencoded
8. Cookie:
KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
KEYCLOAK_REMEMBER_ME=username:alain
9. Host:
localhost:8080
10. Origin:
http://127.0.0.1:8888
11. Referer:
http://127.0.0.1:8888/Main.html
12. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Form Dataview sourceview URL encoded
1. code:
sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
7. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
POST
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Expose-Headers:
Access-Control-Allow-Methods
6. Access-Control-Max-Age:
3600
7. Connection:
keep-alive
8. Content-Type:
application/json
9. Date:
Tue, 02 Dec 2014 14:51:47 GMT
10. Server:
WildFly/8
11. Transfer-Encoding:
chunked
12. X-Powered-By:
Undertow/1
Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
this uses the refresh URI for the first time, Chrome performs a preflight
check:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
3. Request Method:
OPTIONS
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate, sdch
3. Accept-Language:
en-US,en;q=0.8
4. Access-Control-Request-Headers:
authorization, content-type
5. Access-Control-Request-Method:
POST
6. Connection:
keep-alive
7. Host:
localhost:8080
8. Origin:
http://127.0.0.1:8888
9. Referer:
http://127.0.0.1:8888/Main.html
10. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
GET, HEAD, OPTIONS
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Max-Age:
3600
6. Connection:
keep-alive
7. Content-Length:
0
8. Date:
Tue, 02 Dec 2014 15:00:32 GMT
9. Server:
WildFly/8
10. X-Powered-By:
Undertow/1
Followed by the actual refresh:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
3. Request Method:
POST
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate
3. Accept-Language:
en-US,en;q=0.8
4. Authorization:
Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
5. Connection:
keep-alive
6. Content-Length:
699
7. Content-type:
application/x-www-form-urlencoded
8. Host:
localhost:8080
9. Origin:
http://127.0.0.1:8888
10. Referer:
http://127.0.0.1:8888/Main.html
11. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Form Dataview sourceview URL encoded
1. grant_type:
refresh_token
2. refresh_token:
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
7. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
POST
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Expose-Headers:
Access-Control-Allow-Methods
6. Access-Control-Max-Age:
3600
7. Connection:
keep-alive
8. Content-Type:
application/json
9. Date:
Tue, 02 Dec 2014 15:00:32 GMT
10. Server:
WildFly/8
11. Transfer-Encoding:
chunked
12. X-Powered-By:
Undertow/1
On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
----- Original Message -----
> From: "Alain Penders" <alain(a)rexorient.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 2 December, 2014 3:43:13 PM
> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>
> I'm testing my UI using GWTs Super Dev Mode, which means its origin is
set
> to http://127.0.0.1:8888. Keycloak runs on http://127.0.0.1:8080/auth
.
Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
request. My guess is that "GWTs Super Dev Mode" sets some custom headers on
all requests.
>
> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian(a)redhat.com>
wrote:
>
> > It's the correct approach to add the preflight. Please send a PR and
we'll
> > merge it.
> >
> > Out of curiosity do you know why it's sending a preflight in your app?
It
> > doesn't when I test it out here, which AFAIK is correct according to
spec
> > (content-type is application/x-www-form-urlencoded and there's no
custom
> > headers set).
> >
> > ----- Original Message -----
> > > From: "Alain Penders" <alain(a)rexorient.com>
> > > To: keycloak-dev(a)lists.jboss.org
> > > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> > >
> > > Hi all,
> > >
> > > I'm building a new app using GWT 2.7 using the Keycloak javascript
> > adapter
> > > and GWT jsInterop. This works extremely well.
> > >
> > > The problem I ran into is if I walk away for 5 minutes and then try
to do
> > > something, the token refresh fails on preflight. As shown in the
> > > documentation, I call keycloak.updateToken(30) to refresh the base
token
> > in
> > > case it has expired. Since in this case it has indeed expired,
keycloak
> > > makes a call to /auth/realms/<myrealm>/tokens/refresh. The OPTIONS
call
> > to
> > > this location doesn't contain the Accept headers, and my app ends up
> > dead in
> > > the water.
> > >
> > > To fix this, I added the following code to OpenIDConnectService:
> > >
> > > /**
> > > * CORS preflight path for refresh token requests
> > > *
> > > * @return
> > > */
> > > @Path("refresh")
> > > @OPTIONS
> > > @Produces(MediaType.APPLICATION_JSON)
> > > public Response refreshAccessTokenPreflight() {
> > > if (logger.isDebugEnabled()) {
> > > logger.debugv("cors request from: {0}",
> > >
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > > }
> > > return Cors.add(request, Response.ok()).auth().preflight().build();
> > > }
> > >
> > > If this wasn't the correct solution for my problem, I'd enjoy
hearing
> > where I
> > > went wrong.
> > >
> > > Thanks,
> > > Alain
> > >
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
9:10 a.m.
The code->token and refresh token requests are being pre-flighted because there's a
'Authorization: Basic' header in there. For a GWT app you should use the
confidential application type, which doesn't require a secret.
----- Original Message -----
From: "Alain Penders" <alain(a)rexorient.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 4:02:15 PM
Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
Not really. It needs CORS for every URI it hits. Refresh is a different
URI from the code->token exchange one it uses initially.
When Keycloak redirects back to the GWT app and the code is exchanged for
the tokens, I see this in the Network trace:
First an OPTIONS request:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
3. Request Method:
OPTIONS
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate, sdch
3. Accept-Language:
en-US,en;q=0.8
4. Access-Control-Request-Headers:
authorization, content-type
5. Access-Control-Request-Method:
POST
6. Connection:
keep-alive
7. Host:
localhost:8080
8. Origin:
http://127.0.0.1:8888
9. Referer:
http://127.0.0.1:8888/Main.html
10. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
GET, HEAD, OPTIONS
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Max-Age:
3600
6. Connection:
keep-alive
7. Content-Length:
0
8. Date:
Tue, 02 Dec 2014 14:51:47 GMT
9. Server:
WildFly/8
10. X-Powered-By:
Undertow/1
Then the actual code exchange request:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
3. Request Method:
POST
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate
3. Accept-Language:
en-US,en;q=0.8
4. Authorization:
Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
5. Connection:
keep-alive
6. Content-Length:
85
7. Content-type:
application/x-www-form-urlencoded
8. Cookie:
KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
KEYCLOAK_REMEMBER_ME=username:alain
9. Host:
localhost:8080
10. Origin:
http://127.0.0.1:8888
11. Referer:
http://127.0.0.1:8888/Main.html
12. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Form Dataview sourceview URL encoded
1. code:
sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
7. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
POST
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Expose-Headers:
Access-Control-Allow-Methods
6. Access-Control-Max-Age:
3600
7. Connection:
keep-alive
8. Content-Type:
application/json
9. Date:
Tue, 02 Dec 2014 14:51:47 GMT
10. Server:
WildFly/8
11. Transfer-Encoding:
chunked
12. X-Powered-By:
Undertow/1
Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
this uses the refresh URI for the first time, Chrome performs a preflight
check:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
3. Request Method:
OPTIONS
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate, sdch
3. Accept-Language:
en-US,en;q=0.8
4. Access-Control-Request-Headers:
authorization, content-type
5. Access-Control-Request-Method:
POST
6. Connection:
keep-alive
7. Host:
localhost:8080
8. Origin:
http://127.0.0.1:8888
9. Referer:
http://127.0.0.1:8888/Main.html
10. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
GET, HEAD, OPTIONS
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Max-Age:
3600
6. Connection:
keep-alive
7. Content-Length:
0
8. Date:
Tue, 02 Dec 2014 15:00:32 GMT
9. Server:
WildFly/8
10. X-Powered-By:
Undertow/1
Followed by the actual refresh:
1. Remote Address:
127.0.0.1:8080
2. Request URL:
http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
3. Request Method:
POST
4. Status Code:
200 OK
5. Request Headersview source
1. Accept:
*/*
2. Accept-Encoding:
gzip, deflate
3. Accept-Language:
en-US,en;q=0.8
4. Authorization:
Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
5. Connection:
keep-alive
6. Content-Length:
699
7. Content-type:
application/x-www-form-urlencoded
8. Host:
localhost:8080
9. Origin:
http://127.0.0.1:8888
10. Referer:
http://127.0.0.1:8888/Main.html
11. User-Agent:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
6. Form Dataview sourceview URL encoded
1. grant_type:
refresh_token
2. refresh_token:
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
7. Response Headersview source
1. Access-Control-Allow-Credentials:
true
2. Access-Control-Allow-Headers:
Origin, Accept, X-Requested-With, Content-Type,
Access-Control-Request-Method, Access-Control-Request-Headers,
Authorization
3. Access-Control-Allow-Methods:
POST
4. Access-Control-Allow-Origin:
http://127.0.0.1:8888
5. Access-Control-Expose-Headers:
Access-Control-Allow-Methods
6. Access-Control-Max-Age:
3600
7. Connection:
keep-alive
8. Content-Type:
application/json
9. Date:
Tue, 02 Dec 2014 15:00:32 GMT
10. Server:
WildFly/8
11. Transfer-Encoding:
chunked
12. X-Powered-By:
Undertow/1
On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Alain Penders" <alain(a)rexorient.com>
> > To: "Stian Thorgersen" <stian(a)redhat.com>
> > Cc: keycloak-dev(a)lists.jboss.org
> > Sent: Tuesday, 2 December, 2014 3:43:13 PM
> > Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
> >
> > I'm testing my UI using GWTs Super Dev Mode, which means its origin is
> set
> > to http://127.0.0.1:8888. Keycloak runs on http://127.0.0.1:8080/auth
> .
>
> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
> request. My guess is that "GWTs Super Dev Mode" sets some custom headers
on
> all requests.
>
> >
> > On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian(a)redhat.com>
> wrote:
> >
> > > It's the correct approach to add the preflight. Please send a PR and
> we'll
> > > merge it.
> > >
> > > Out of curiosity do you know why it's sending a preflight in your
app?
> It
> > > doesn't when I test it out here, which AFAIK is correct according to
> spec
> > > (content-type is application/x-www-form-urlencoded and there's no
> custom
> > > headers set).
> > >
> > > ----- Original Message -----
> > > > From: "Alain Penders" <alain(a)rexorient.com>
> > > > To: keycloak-dev(a)lists.jboss.org
> > > > Sent: Tuesday, 2 December, 2014 3:04:50 PM
> > > > Subject: [keycloak-dev] Fwd: Preflight for token refresh
> > > >
> > > > Hi all,
> > > >
> > > > I'm building a new app using GWT 2.7 using the Keycloak
javascript
> > > adapter
> > > > and GWT jsInterop. This works extremely well.
> > > >
> > > > The problem I ran into is if I walk away for 5 minutes and then try
> to do
> > > > something, the token refresh fails on preflight. As shown in the
> > > > documentation, I call keycloak.updateToken(30) to refresh the base
> token
> > > in
> > > > case it has expired. Since in this case it has indeed expired,
> keycloak
> > > > makes a call to /auth/realms/<myrealm>/tokens/refresh. The
OPTIONS
> call
> > > to
> > > > this location doesn't contain the Accept headers, and my app ends
up
> > > dead in
> > > > the water.
> > > >
> > > > To fix this, I added the following code to OpenIDConnectService:
> > > >
> > > > /**
> > > > * CORS preflight path for refresh token requests
> > > > *
> > > > * @return
> > > > */
> > > > @Path("refresh")
> > > > @OPTIONS
> > > > @Produces(MediaType.APPLICATION_JSON)
> > > > public Response refreshAccessTokenPreflight() {
> > > > if (logger.isDebugEnabled()) {
> > > > logger.debugv("cors request from: {0}",
> > > >
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
> > > > }
> > > > return Cors.add(request, Response.ok()).auth().preflight().build();
> > > > }
> > > >
> > > > If this wasn't the correct solution for my problem, I'd enjoy
hearing
> > > where I
> > > > went wrong.
> > > >
> > > > Thanks,
> > > > Alain
> > > >
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> >
>
9:24 a.m.
You mean the "public" application type.
On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
The code->token and refresh token requests are being pre-flighted
because there's a 'Authorization: Basic' header in there. For a GWT app you
should use the confidential application type, which doesn't require a secret.
----- Original Message -----
> From: "Alain Penders" <alain(a)rexorient.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 2 December, 2014 4:02:15 PM
> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>
> Not really. It needs CORS for every URI it hits. Refresh is a different
> URI from the code->token exchange one it uses initially.
>
> When Keycloak redirects back to the GWT app and the code is exchanged for
> the tokens, I see this in the Network trace:
>
> First an OPTIONS request:
>
>
> 1. Remote Address:
> 127.0.0.1:8080
> 2. Request URL:
> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> 3. Request Method:
> OPTIONS
> 4. Status Code:
> 200 OK
> 5. Request Headersview source
> 1. Accept:
> */*
> 2. Accept-Encoding:
> gzip, deflate, sdch
> 3. Accept-Language:
> en-US,en;q=0.8
> 4. Access-Control-Request-Headers:
> authorization, content-type
> 5. Access-Control-Request-Method:
> POST
> 6. Connection:
> keep-alive
> 7. Host:
> localhost:8080
> 8. Origin:
> http://127.0.0.1:8888
> 9. Referer:
> http://127.0.0.1:8888/Main.html
> 10. User-Agent:
> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/39.0.2171.71 Safari/537.36
> 6. Response Headersview source
> 1. Access-Control-Allow-Credentials:
> true
> 2. Access-Control-Allow-Headers:
> Origin, Accept, X-Requested-With, Content-Type,
> Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
> 3. Access-Control-Allow-Methods:
> GET, HEAD, OPTIONS
> 4. Access-Control-Allow-Origin:
> http://127.0.0.1:8888
> 5. Access-Control-Max-Age:
> 3600
> 6. Connection:
> keep-alive
> 7. Content-Length:
> 0
> 8. Date:
> Tue, 02 Dec 2014 14:51:47 GMT
> 9. Server:
> WildFly/8
> 10. X-Powered-By:
> Undertow/1
>
>
> Then the actual code exchange request:
>
>
> 1. Remote Address:
> 127.0.0.1:8080
> 2. Request URL:
> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
> 3. Request Method:
> POST
> 4. Status Code:
> 200 OK
> 5. Request Headersview source
> 1. Accept:
> */*
> 2. Accept-Encoding:
> gzip, deflate
> 3. Accept-Language:
> en-US,en;q=0.8
> 4. Authorization:
> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> 5. Connection:
> keep-alive
> 6. Content-Length:
> 85
> 7. Content-type:
> application/x-www-form-urlencoded
> 8. Cookie:
>
KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
>
KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
> KEYCLOAK_REMEMBER_ME=username:alain
> 9. Host:
> localhost:8080
> 10. Origin:
> http://127.0.0.1:8888
> 11. Referer:
> http://127.0.0.1:8888/Main.html
> 12. User-Agent:
> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/39.0.2171.71 Safari/537.36
> 6. Form Dataview sourceview URL encoded
> 1. code:
>
>
sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
> 7. Response Headersview source
> 1. Access-Control-Allow-Credentials:
> true
> 2. Access-Control-Allow-Headers:
> Origin, Accept, X-Requested-With, Content-Type,
> Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
> 3. Access-Control-Allow-Methods:
> POST
> 4. Access-Control-Allow-Origin:
> http://127.0.0.1:8888
> 5. Access-Control-Expose-Headers:
> Access-Control-Allow-Methods
> 6. Access-Control-Max-Age:
> 3600
> 7. Connection:
> keep-alive
> 8. Content-Type:
> application/json
> 9. Date:
> Tue, 02 Dec 2014 14:51:47 GMT
> 10. Server:
> WildFly/8
> 11. Transfer-Encoding:
> chunked
> 12. X-Powered-By:
> Undertow/1
>
>
> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
> this uses the refresh URI for the first time, Chrome performs a preflight
> check:
>
>
> 1. Remote Address:
> 127.0.0.1:8080
> 2. Request URL:
> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> 3. Request Method:
> OPTIONS
> 4. Status Code:
> 200 OK
> 5. Request Headersview source
> 1. Accept:
> */*
> 2. Accept-Encoding:
> gzip, deflate, sdch
> 3. Accept-Language:
> en-US,en;q=0.8
> 4. Access-Control-Request-Headers:
> authorization, content-type
> 5. Access-Control-Request-Method:
> POST
> 6. Connection:
> keep-alive
> 7. Host:
> localhost:8080
> 8. Origin:
> http://127.0.0.1:8888
> 9. Referer:
> http://127.0.0.1:8888/Main.html
> 10. User-Agent:
> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/39.0.2171.71 Safari/537.36
> 6. Response Headersview source
> 1. Access-Control-Allow-Credentials:
> true
> 2. Access-Control-Allow-Headers:
> Origin, Accept, X-Requested-With, Content-Type,
> Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
> 3. Access-Control-Allow-Methods:
> GET, HEAD, OPTIONS
> 4. Access-Control-Allow-Origin:
> http://127.0.0.1:8888
> 5. Access-Control-Max-Age:
> 3600
> 6. Connection:
> keep-alive
> 7. Content-Length:
> 0
> 8. Date:
> Tue, 02 Dec 2014 15:00:32 GMT
> 9. Server:
> WildFly/8
> 10. X-Powered-By:
> Undertow/1
>
>
> Followed by the actual refresh:
>
>
> 1. Remote Address:
> 127.0.0.1:8080
> 2. Request URL:
> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
> 3. Request Method:
> POST
> 4. Status Code:
> 200 OK
> 5. Request Headersview source
> 1. Accept:
> */*
> 2. Accept-Encoding:
> gzip, deflate
> 3. Accept-Language:
> en-US,en;q=0.8
> 4. Authorization:
> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
> 5. Connection:
> keep-alive
> 6. Content-Length:
> 699
> 7. Content-type:
> application/x-www-form-urlencoded
> 8. Host:
> localhost:8080
> 9. Origin:
> http://127.0.0.1:8888
> 10. Referer:
> http://127.0.0.1:8888/Main.html
> 11. User-Agent:
> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/39.0.2171.71 Safari/537.36
> 6. Form Dataview sourceview URL encoded
> 1. grant_type:
> refresh_token
> 2. refresh_token:
>
>
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
> 7. Response Headersview source
> 1. Access-Control-Allow-Credentials:
> true
> 2. Access-Control-Allow-Headers:
> Origin, Accept, X-Requested-With, Content-Type,
> Access-Control-Request-Method, Access-Control-Request-Headers,
> Authorization
> 3. Access-Control-Allow-Methods:
> POST
> 4. Access-Control-Allow-Origin:
> http://127.0.0.1:8888
> 5. Access-Control-Expose-Headers:
> Access-Control-Allow-Methods
> 6. Access-Control-Max-Age:
> 3600
> 7. Connection:
> keep-alive
> 8. Content-Type:
> application/json
> 9. Date:
> Tue, 02 Dec 2014 15:00:32 GMT
> 10. Server:
> WildFly/8
> 11. Transfer-Encoding:
> chunked
> 12. X-Powered-By:
> Undertow/1
>
>
>
>
> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>>> From: "Alain Penders" <alain(a)rexorient.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>>
>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin is
>> set
>>> to http://127.0.0.1:8888. Keycloak runs on http://127.0.0.1:8080/auth
>> .
>>
>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
>> request. My guess is that "GWTs Super Dev Mode" sets some custom
headers on
>> all requests.
>>
>>>
>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen <stian(a)redhat.com>
>> wrote:
>>>
>>>> It's the correct approach to add the preflight. Please send a PR and
>> we'll
>>>> merge it.
>>>>
>>>> Out of curiosity do you know why it's sending a preflight in your
app?
>> It
>>>> doesn't when I test it out here, which AFAIK is correct according to
>> spec
>>>> (content-type is application/x-www-form-urlencoded and there's no
>> custom
>>>> headers set).
>>>>
>>>> ----- Original Message -----
>>>>> From: "Alain Penders" <alain(a)rexorient.com>
>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm building a new app using GWT 2.7 using the Keycloak
javascript
>>>> adapter
>>>>> and GWT jsInterop. This works extremely well.
>>>>>
>>>>> The problem I ran into is if I walk away for 5 minutes and then try
>> to do
>>>>> something, the token refresh fails on preflight. As shown in the
>>>>> documentation, I call keycloak.updateToken(30) to refresh the base
>> token
>>>> in
>>>>> case it has expired. Since in this case it has indeed expired,
>> keycloak
>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The
OPTIONS
>> call
>>>> to
>>>>> this location doesn't contain the Accept headers, and my app ends
up
>>>> dead in
>>>>> the water.
>>>>>
>>>>> To fix this, I added the following code to OpenIDConnectService:
>>>>>
>>>>> /**
>>>>> * CORS preflight path for refresh token requests
>>>>> *
>>>>> * @return
>>>>> */
>>>>> @Path("refresh")
>>>>> @OPTIONS
>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>> public Response refreshAccessTokenPreflight() {
>>>>> if (logger.isDebugEnabled()) {
>>>>> logger.debugv("cors request from: {0}",
>>>>>
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
>>>>> }
>>>>> return Cors.add(request, Response.ok()).auth().preflight().build();
>>>>> }
>>>>>
>>>>> If this wasn't the correct solution for my problem, I'd enjoy
hearing
>>>> where I
>>>>> went wrong.
>>>>>
>>>>> Thanks,
>>>>> Alain
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:33 a.m.
I was about to say "I am using confidential". Switching to public does
indeed drop the need for preflight. Learned something new :-)
Still want me to submit a PR for the refresh preflight? Obviously using
confidential doesn't add any security here, but I don't think supporting it
can hurt either (and the JavaScript code supports it already.)
On Tue, Dec 2, 2014 at 8:24 AM, Bill Burke <bburke(a)redhat.com> wrote:
You mean the "public" application type.
On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
> The code->token and refresh token requests are being pre-flighted
because there's a 'Authorization: Basic' header in there. For a GWT app you
should use the confidential application type, which doesn't require a
secret.
>
> ----- Original Message -----
>> From: "Alain Penders" <alain(a)rexorient.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 4:02:15 PM
>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>
>> Not really. It needs CORS for every URI it hits. Refresh is a
different
>> URI from the code->token exchange one it uses initially.
>>
>> When Keycloak redirects back to the GWT app and the code is exchanged
for
>> the tokens, I see this in the Network trace:
>>
>> First an OPTIONS request:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>> 3. Request Method:
>> OPTIONS
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate, sdch
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Access-Control-Request-Headers:
>> authorization, content-type
>> 5. Access-Control-Request-Method:
>> POST
>> 6. Connection:
>> keep-alive
>> 7. Host:
>> localhost:8080
>> 8. Origin:
>> http://127.0.0.1:8888
>> 9. Referer:
>> http://127.0.0.1:8888/Main.html
>> 10. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> GET, HEAD, OPTIONS
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Max-Age:
>> 3600
>> 6. Connection:
>> keep-alive
>> 7. Content-Length:
>> 0
>> 8. Date:
>> Tue, 02 Dec 2014 14:51:47 GMT
>> 9. Server:
>> WildFly/8
>> 10. X-Powered-By:
>> Undertow/1
>>
>>
>> Then the actual code exchange request:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>> 3. Request Method:
>> POST
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Authorization:
>> Basic
R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>> 5. Connection:
>> keep-alive
>> 6. Content-Length:
>> 85
>> 7. Content-type:
>> application/x-www-form-urlencoded
>> 8. Cookie:
>>
KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
>>
KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
>> KEYCLOAK_REMEMBER_ME=username:alain
>> 9. Host:
>> localhost:8080
>> 10. Origin:
>> http://127.0.0.1:8888
>> 11. Referer:
>> http://127.0.0.1:8888/Main.html
>> 12. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Form Dataview sourceview URL encoded
>> 1. code:
>>
>>
sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
>> 7. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> POST
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Expose-Headers:
>> Access-Control-Allow-Methods
>> 6. Access-Control-Max-Age:
>> 3600
>> 7. Connection:
>> keep-alive
>> 8. Content-Type:
>> application/json
>> 9. Date:
>> Tue, 02 Dec 2014 14:51:47 GMT
>> 10. Server:
>> WildFly/8
>> 11. Transfer-Encoding:
>> chunked
>> 12. X-Powered-By:
>> Undertow/1
>>
>>
>> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
>> this uses the refresh URI for the first time, Chrome performs a
preflight
>> check:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>> 3. Request Method:
>> OPTIONS
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate, sdch
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Access-Control-Request-Headers:
>> authorization, content-type
>> 5. Access-Control-Request-Method:
>> POST
>> 6. Connection:
>> keep-alive
>> 7. Host:
>> localhost:8080
>> 8. Origin:
>> http://127.0.0.1:8888
>> 9. Referer:
>> http://127.0.0.1:8888/Main.html
>> 10. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> GET, HEAD, OPTIONS
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Max-Age:
>> 3600
>> 6. Connection:
>> keep-alive
>> 7. Content-Length:
>> 0
>> 8. Date:
>> Tue, 02 Dec 2014 15:00:32 GMT
>> 9. Server:
>> WildFly/8
>> 10. X-Powered-By:
>> Undertow/1
>>
>>
>> Followed by the actual refresh:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>> 3. Request Method:
>> POST
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Authorization:
>> Basic
R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>> 5. Connection:
>> keep-alive
>> 6. Content-Length:
>> 699
>> 7. Content-type:
>> application/x-www-form-urlencoded
>> 8. Host:
>> localhost:8080
>> 9. Origin:
>> http://127.0.0.1:8888
>> 10. Referer:
>> http://127.0.0.1:8888/Main.html
>> 11. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML,
like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Form Dataview sourceview URL encoded
>> 1. grant_type:
>> refresh_token
>> 2. refresh_token:
>>
>>
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
>> 7. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> POST
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Expose-Headers:
>> Access-Control-Allow-Methods
>> 6. Access-Control-Max-Age:
>> 3600
>> 7. Connection:
>> keep-alive
>> 8. Content-Type:
>> application/json
>> 9. Date:
>> Tue, 02 Dec 2014 15:00:32 GMT
>> 10. Server:
>> WildFly/8
>> 11. Transfer-Encoding:
>> chunked
>> 12. X-Powered-By:
>> Undertow/1
>>
>>
>>
>>
>> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen <stian(a)redhat.com>
wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alain Penders" <alain(a)rexorient.com>
>>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
>>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>>>
>>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin
is
>>> set
>>>> to http://127.0.0.1:8888. Keycloak runs on
http://127.0.0.1:8080/auth
>>> .
>>>
>>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
>>> request. My guess is that "GWTs Super Dev Mode" sets some custom
headers on
>>> all requests.
>>>
>>>>
>>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen
<stian(a)redhat.com>
>>> wrote:
>>>>
>>>>> It's the correct approach to add the preflight. Please send a PR
and
>>> we'll
>>>>> merge it.
>>>>>
>>>>> Out of curiosity do you know why it's sending a preflight in
your
app?
>>> It
>>>>> doesn't when I test it out here, which AFAIK is correct
according to
>>> spec
>>>>> (content-type is application/x-www-form-urlencoded and there's
no
>>> custom
>>>>> headers set).
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alain Penders" <alain(a)rexorient.com>
>>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
>>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm building a new app using GWT 2.7 using the Keycloak
javascript
>>>>> adapter
>>>>>> and GWT jsInterop. This works extremely well.
>>>>>>
>>>>>> The problem I ran into is if I walk away for 5 minutes and then
try
>>> to do
>>>>>> something, the token refresh fails on preflight. As shown in
the
>>>>>> documentation, I call keycloak.updateToken(30) to refresh the
base
>>> token
>>>>> in
>>>>>> case it has expired. Since in this case it has indeed expired,
>>> keycloak
>>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The
OPTIONS
>>> call
>>>>> to
>>>>>> this location doesn't contain the Accept headers, and my app
ends up
>>>>> dead in
>>>>>> the water.
>>>>>>
>>>>>> To fix this, I added the following code to
OpenIDConnectService:
>>>>>>
>>>>>> /**
>>>>>> * CORS preflight path for refresh token requests
>>>>>> *
>>>>>> * @return
>>>>>> */
>>>>>> @Path("refresh")
>>>>>> @OPTIONS
>>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>>> public Response refreshAccessTokenPreflight() {
>>>>>> if (logger.isDebugEnabled()) {
>>>>>> logger.debugv("cors request from: {0}",
>>>>>>
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
>>>>>> }
>>>>>> return Cors.add(request,
Response.ok()).auth().preflight().build();
>>>>>> }
>>>>>>
>>>>>> If this wasn't the correct solution for my problem, I'd
enjoy
hearing
>>>>> where I
>>>>>> went wrong.
>>>>>>
>>>>>> Thanks,
>>>>>> Alain
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:40 a.m.
Yes, I meant public ;)
Yes, please do the PR. I can't see any harm in supporting PREFLIGHT, in fact we
already do for code->token.
----- Original Message -----
From: "Alain Penders" <alain(a)rexorient.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 4:33:54 PM
Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
I was about to say "I am using confidential". Switching to public does indeed
drop the need for preflight. Learned something new :-)
Still want me to submit a PR for the refresh preflight? Obviously using
confidential doesn't add any security here, but I don't think supporting it
can hurt either (and the JavaScript code supports it already.)
On Tue, Dec 2, 2014 at 8:24 AM, Bill Burke < bburke(a)redhat.com > wrote:
You mean the "public" application type.
On 12/2/2014 10:10 AM, Stian Thorgersen wrote:
> The code->token and refresh token requests are being pre-flighted because
> there's a 'Authorization: Basic' header in there. For a GWT app you
should
> use the confidential application type, which doesn't require a secret.
>
> ----- Original Message -----
>> From: "Alain Penders" < alain(a)rexorient.com >
>> To: "Stian Thorgersen" < stian(a)redhat.com >
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 4:02:15 PM
>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>
>> Not really. It needs CORS for every URI it hits. Refresh is a different
>> URI from the code->token exchange one it uses initially.
>>
>> When Keycloak redirects back to the GWT app and the code is exchanged for
>> the tokens, I see this in the Network trace:
>>
>> First an OPTIONS request:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>> 3. Request Method:
>> OPTIONS
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate, sdch
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Access-Control-Request-Headers:
>> authorization, content-type
>> 5. Access-Control-Request-Method:
>> POST
>> 6. Connection:
>> keep-alive
>> 7. Host:
>> localhost:8080
>> 8. Origin:
>> http://127.0.0.1:8888
>> 9. Referer:
>> http://127.0.0.1:8888/Main.html
>> 10. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> GET, HEAD, OPTIONS
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Max-Age:
>> 3600
>> 6. Connection:
>> keep-alive
>> 7. Content-Length:
>> 0
>> 8. Date:
>> Tue, 02 Dec 2014 14:51:47 GMT
>> 9. Server:
>> WildFly/8
>> 10. X-Powered-By:
>> Undertow/1
>>
>>
>> Then the actual code exchange request:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/access/codes
>> 3. Request Method:
>> POST
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Authorization:
>> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>> 5. Connection:
>> keep-alive
>> 6. Content-Length:
>> 85
>> 7. Content-type:
>> application/x-www-form-urlencoded
>> 8. Cookie:
>>
KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5NTA4ZTg2Yi04ZjdhLTRmN2UtOWYzOC1jMTFhMDdkNjUyOWMiLCJleHAiOjE0MjAxMjM5MDYsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA2LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwic2Vzc2lvbl9zdGF0ZSI6ImVjODE0NjcyLTFhOWYtNDM1ZS04YjU4LTU4ZmI4MDNiMDZkYSIsInJlc291cmNlX2FjY2VzcyI6e319.LiS51MggFZVPJ-TUlcYejPD7x6pJvgdOYCLrHV8LKiIP6BGZzS7D4W0t3xsXeKxqBr-h3cSaY_BqWKRl4RGn67SHuWvoDRrS6xKPZuWPQ08NS_iQVrIKGOATtGF2VFMutnroa4Y_UNmi5T2gZFc-wphRWRV5YG-x-DGAqd4h42U;
>>
KEYCLOAK_SESSION=GameSeeder/964f905c-e86d-4453-a732-aee0194f9a20/ec814672-1a9f-435e-8b58-58fb803b06da;
>> KEYCLOAK_REMEMBER_ME=username:alain
>> 9. Host:
>> localhost:8080
>> 10. Origin:
>> http://127.0.0.1:8888
>> 11. Referer:
>> http://127.0.0.1:8888/Main.html
>> 12. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Form Dataview sourceview URL encoded
>> 1. code:
>>
>>
sCnqEAuF8YuobscjJnCKdGu6xqnZ-CsqT5prXc5i7os.b9cda44e-50d6-49dd-b30a-dee68b530662
>> 7. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> POST
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Expose-Headers:
>> Access-Control-Allow-Methods
>> 6. Access-Control-Max-Age:
>> 3600
>> 7. Connection:
>> keep-alive
>> 8. Content-Type:
>> application/json
>> 9. Date:
>> Tue, 02 Dec 2014 14:51:47 GMT
>> 10. Server:
>> WildFly/8
>> 11. Transfer-Encoding:
>> chunked
>> 12. X-Powered-By:
>> Undertow/1
>>
>>
>> Now I wait 5+ minutes, forcing keycloak to use the refresh token. Since
>> this uses the refresh URI for the first time, Chrome performs a preflight
>> check:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>> 3. Request Method:
>> OPTIONS
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate, sdch
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Access-Control-Request-Headers:
>> authorization, content-type
>> 5. Access-Control-Request-Method:
>> POST
>> 6. Connection:
>> keep-alive
>> 7. Host:
>> localhost:8080
>> 8. Origin:
>> http://127.0.0.1:8888
>> 9. Referer:
>> http://127.0.0.1:8888/Main.html
>> 10. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> GET, HEAD, OPTIONS
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Max-Age:
>> 3600
>> 6. Connection:
>> keep-alive
>> 7. Content-Length:
>> 0
>> 8. Date:
>> Tue, 02 Dec 2014 15:00:32 GMT
>> 9. Server:
>> WildFly/8
>> 10. X-Powered-By:
>> Undertow/1
>>
>>
>> Followed by the actual refresh:
>>
>>
>> 1. Remote Address:
>> 127.0.0.1:8080
>> 2. Request URL:
>> http://localhost:8080/auth/realms/GameSeeder/tokens/refresh
>> 3. Request Method:
>> POST
>> 4. Status Code:
>> 200 OK
>> 5. Request Headersview source
>> 1. Accept:
>> */*
>> 2. Accept-Encoding:
>> gzip, deflate
>> 3. Accept-Language:
>> en-US,en;q=0.8
>> 4. Authorization:
>> Basic R2FtZVNlZWRlcjoyYTczYTQ0Yi1lMGFhLTRiMTYtODk2OC1hY2YwZTVlMGVlNTk=
>> 5. Connection:
>> keep-alive
>> 6. Content-Length:
>> 699
>> 7. Content-type:
>> application/x-www-form-urlencoded
>> 8. Host:
>> localhost:8080
>> 9. Origin:
>> http://127.0.0.1:8888
>> 10. Referer:
>> http://127.0.0.1:8888/Main.html
>> 11. User-Agent:
>> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
>> Gecko) Chrome/39.0.2171.71 Safari/537.36
>> 6. Form Dataview sourceview URL encoded
>> 1. grant_type:
>> refresh_token
>> 2. refresh_token:
>>
>>
eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJjMWZlOGUyNS0yNTlkLTQwYjYtOGFmMS0yMDU0Y2EwMTRkYWEiLCJleHAiOjE0MTc1MzkxMDcsIm5iZiI6MCwiaWF0IjoxNDE3NTMxOTA3LCJpc3MiOiJHYW1lU2VlZGVyIiwic3ViIjoiOTY0ZjkwNWMtZTg2ZC00NDUzLWE3MzItYWVlMDE5NGY5YTIwIiwidHlwIjoiUkVGUkVTSCIsImF6cCI6IkdhbWVTZWVkZXIiLCJzZXNzaW9uX3N0YXRlIjoiZWM4MTQ2NzItMWE5Zi00MzVlLThiNTgtNThmYjgwM2IwNmRhIiwicmVhbG1fYWNjZXNzIjp7InJvbGVzIjpbInVzZXIiXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbInZpZXctcHJvZmlsZSIsIm1hbmFnZS1hY2NvdW50Il19fX0.HlAXTyosQ4SHL2WyqRVMDEwN2TXNQyqTKE8PRkbhnbhjJPq4alDP2mCBH2RV3a5KPDCTj1-H-bnKpebrV8fOWNVrQCCL5NN6t7KEYLH1hA75ak_xWSUNzz7s_ZlW9AVucuMCFk1-bXnDaQOilU9JOS2yomQYa4PvexmrbzEJ5Bs
>> 7. Response Headersview source
>> 1. Access-Control-Allow-Credentials:
>> true
>> 2. Access-Control-Allow-Headers:
>> Origin, Accept, X-Requested-With, Content-Type,
>> Access-Control-Request-Method, Access-Control-Request-Headers,
>> Authorization
>> 3. Access-Control-Allow-Methods:
>> POST
>> 4. Access-Control-Allow-Origin:
>> http://127.0.0.1:8888
>> 5. Access-Control-Expose-Headers:
>> Access-Control-Allow-Methods
>> 6. Access-Control-Max-Age:
>> 3600
>> 7. Connection:
>> keep-alive
>> 8. Content-Type:
>> application/json
>> 9. Date:
>> Tue, 02 Dec 2014 15:00:32 GMT
>> 10. Server:
>> WildFly/8
>> 11. Transfer-Encoding:
>> chunked
>> 12. X-Powered-By:
>> Undertow/1
>>
>>
>>
>>
>> On Tue, Dec 2, 2014 at 7:49 AM, Stian Thorgersen < stian(a)redhat.com >
>> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Alain Penders" < alain(a)rexorient.com >
>>>> To: "Stian Thorgersen" < stian(a)redhat.com >
>>>> Cc: keycloak-dev(a)lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 3:43:13 PM
>>>> Subject: Re: [keycloak-dev] Fwd: Preflight for token refresh
>>>>
>>>> I'm testing my UI using GWTs Super Dev Mode, which means its origin
is
>>> set
>>>> to http://127.0.0.1:8888 . Keycloak runs on http://127.0.0.1:8080/auth
>>> .
>>>
>>> Yes, that requires CORS, but doesn't necessarily require a PREFLIGHT
>>> request. My guess is that "GWTs Super Dev Mode" sets some custom
headers
>>> on
>>> all requests.
>>>
>>>>
>>>> On Tue, Dec 2, 2014 at 7:32 AM, Stian Thorgersen < stian(a)redhat.com
>
>>> wrote:
>>>>
>>>>> It's the correct approach to add the preflight. Please send a PR
and
>>> we'll
>>>>> merge it.
>>>>>
>>>>> Out of curiosity do you know why it's sending a preflight in
your app?
>>> It
>>>>> doesn't when I test it out here, which AFAIK is correct
according to
>>> spec
>>>>> (content-type is application/x-www-form-urlencoded and there's
no
>>> custom
>>>>> headers set).
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Alain Penders" < alain(a)rexorient.com >
>>>>>> To: keycloak-dev(a)lists.jboss.org
>>>>>> Sent: Tuesday, 2 December, 2014 3:04:50 PM
>>>>>> Subject: [keycloak-dev] Fwd: Preflight for token refresh
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm building a new app using GWT 2.7 using the Keycloak
javascript
>>>>> adapter
>>>>>> and GWT jsInterop. This works extremely well.
>>>>>>
>>>>>> The problem I ran into is if I walk away for 5 minutes and then
try
>>> to do
>>>>>> something, the token refresh fails on preflight. As shown in
the
>>>>>> documentation, I call keycloak.updateToken(30) to refresh the
base
>>> token
>>>>> in
>>>>>> case it has expired. Since in this case it has indeed expired,
>>> keycloak
>>>>>> makes a call to /auth/realms/<myrealm>/tokens/refresh. The
OPTIONS
>>> call
>>>>> to
>>>>>> this location doesn't contain the Accept headers, and my app
ends up
>>>>> dead in
>>>>>> the water.
>>>>>>
>>>>>> To fix this, I added the following code to
OpenIDConnectService:
>>>>>>
>>>>>> /**
>>>>>> * CORS preflight path for refresh token requests
>>>>>> *
>>>>>> * @return
>>>>>> */
>>>>>> @Path("refresh")
>>>>>> @OPTIONS
>>>>>> @Produces(MediaType.APPLICATION_JSON)
>>>>>> public Response refreshAccessTokenPreflight() {
>>>>>> if (logger.isDebugEnabled()) {
>>>>>> logger.debugv("cors request from: {0}",
>>>>>>
request.getHttpHeaders().getRequestHeaders().getFirst("Origin"));
>>>>>> }
>>>>>> return Cors.add(request,
Response.ok()).auth().preflight().build();
>>>>>> }
>>>>>>
>>>>>> If this wasn't the correct solution for my problem, I'd
enjoy hearing
>>>>> where I
>>>>>> went wrong.
>>>>>>
>>>>>> Thanks,
>>>>>> Alain
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3677
days inactive
3677
days old
8 comments
3 participants
participants (3)
-
Alain Penders -
Bill Burke -
Stian Thorgersen