[JBoss JIRA] (RTGOV-663) Nested SwitchYard service calls are not logged correctly
by Sascha Dirbach (JIRA)
[ https://issues.jboss.org/browse/RTGOV-663?page=com.atlassian.jira.plugin.... ]
Sascha Dirbach updated RTGOV-663:
---------------------------------
Attachment: sy-sca-rtgov.zip
Reproducer
> Nested SwitchYard service calls are not logged correctly
> --------------------------------------------------------
>
> Key: RTGOV-663
> URL: https://issues.jboss.org/browse/RTGOV-663
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Components: Activity Collector
> Affects Versions: 2.1.0.Beta1
> Environment: Tested on:
> JBoss FSW 6.0.0 with RTGov UI Version 2 and
> RTGov Distribution with SwithchYard 2 & JBoss EAP 6.4
> Reporter: Sascha Dirbach
> Assignee: Gary Brown
> Attachments: sy-sca-rtgov.zip
>
>
> When I have a SwitchYard Project with a nested service call in the same Thread (e.g. same-machine SCA service) the outer invocation information is lost in the activity collector, as the ActivityUnit is kept in a ThreadLocal member variable of org.overlord.rtgov.activity.collector.AbstractActivityCollector. By calling the nested service, the previous (outer) ActivityUnit is lost.
> The source code comments & documentation state that nested calls of startScope & endScope are not supported, but I think SwitchYard services with nested service calls in the same Thread are not uncommon.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (RTGOV-663) Nested SwitchYard service calls are not logged correctly
by Sascha Dirbach (JIRA)
Sascha Dirbach created RTGOV-663:
------------------------------------
Summary: Nested SwitchYard service calls are not logged correctly
Key: RTGOV-663
URL: https://issues.jboss.org/browse/RTGOV-663
Project: RTGov (Run Time Governance)
Issue Type: Bug
Components: Activity Collector
Affects Versions: 2.1.0.Beta1
Environment: Tested on:
JBoss FSW 6.0.0 with RTGov UI Version 2 and
RTGov Distribution with SwithchYard 2 & JBoss EAP 6.4
Reporter: Sascha Dirbach
Assignee: Gary Brown
Attachments: sy-sca-rtgov.zip
When I have a SwitchYard Project with a nested service call in the same Thread (e.g. same-machine SCA service) the outer invocation information is lost in the activity collector, as the ActivityUnit is kept in a ThreadLocal member variable of org.overlord.rtgov.activity.collector.AbstractActivityCollector. By calling the nested service, the previous (outer) ActivityUnit is lost.
The source code comments & documentation state that nested calls of startScope & endScope are not supported, but I think SwitchYard services with nested service calls in the same Thread are not uncommon.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-748:
-----------------------------------
[~csa], thanks much for that. I'd rather address the issues with Keycloak, rather than spin your gears on workarounds. But, thanks for ensuring I hadn't completely lost my mind ;)
And yes, Artificer upgraded to Errai 3 a while back.
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Christian Sadilek (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Christian Sadilek commented on ARTIF-748:
-----------------------------------------
[~brmeyer], I agree with your summary. Since the response code is 200 OK, Errai will try to demarshall the response which it expects to be JSON-based, as specified in @Consumes and @Produces. So, the server is really returning an invalid response and you will see an unhandled exception.
Interceptors are probably not an ideal solution here as you don't know which REST call will fail after the token expired, so you'd have to intercept them all.
I could easily add error handling for this case to Errai 3.2, if needed. BTW, did you already upgrade to 3.2 and GWT 2.7?
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-748:
-----------------------------------
Primarily caused by KEYCLOAK-1539. If we could configure the realm to simply respond with 401, rather than the login HTML, I'm guessing this would be a lot more straight forward...
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-748:
-----------------------------------
Thanks [~eric.wittmann].
[~csa], any thoughts on that? See my comment on KEYCLOAK-1539. Essentially, a call to JSON REST using Errai's Caller may be unauthorized. But instead of returning a 401 (or anything helpful), KeyCloak returns a login page's HTML. GWT's JSON marshallers, of course, fall over themselves. However, I was a little surprised that the error didn't hit the Caller's ErrorHandler *at all*. Should it? I'll need to play with it again to come up with a stacktrace. But regardless, if a GWT marshaller throws an exception on a REST call, could that bubble up to the ErrorHandler somehow? Or, is there a way to deal with this with some sort of Interceptor, like Eric suggested?
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on ARTIF-748:
-------------------------------------
Looks right to me. Although I thought there might be interceptors you could use either in GWT or Errai which might be able to kick in early enough for you to catch this error. Something to explore perhaps.
http://docs.jboss.org/errai/2.1.0.CR1/errai/reference/html/sid-19398997.h...
Not sure if it's helpful or not. :(
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months
[JBoss JIRA] (ARTIF-748) Web UI: Refresh to /login when Keycloak token expires
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/ARTIF-748?page=com.atlassian.jira.plugin.... ]
Eric Wittmann updated ARTIF-748:
--------------------------------
Description:
If the token expires, the server spits out:
{code}
14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
{code}
The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
Idea: Have a pure Javascript loop "ping" the UI services and check the response.
was:
If the token expires, the server spits out:
14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
Idea: Have a pure Javascript loop "ping" the UI services and check the response.
> Web UI: Refresh to /login when Keycloak token expires
> -----------------------------------------------------
>
> Key: ARTIF-748
> URL: https://issues.jboss.org/browse/ARTIF-748
> Project: Artificer
> Issue Type: Task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> If the token expires, the server spits out:
> {code}
> 14:25:07,534 WARN [org.keycloak.events] (default task-36) type=REFRESH_TOKEN_ERROR, realmId=0c4049da-2746-468e-ab6d-49e51dd1f133, clientId=artificer-ui, userId=null, ipAddress=127.0.0.1, error=invalid_token
> 14:25:07,560 ERROR [org.keycloak.adapters.RefreshableKeycloakSecurityContext] (default task-37) Refresh token failure status: 400 {"error_description":"Refresh token expired","error":"invalid_grant"}
> {code}
> The next time the browser makes a call to the UI services, Errai reports an uncaught GWT exception. That call *must* be protected by Keycloak, in order for our Filter to pick up the KeycloakSecurityContext and create the bearer token. However, the GWT exception shows that the Keycloak *login page* is being served on the call, so Errai's JSON marshaller barfs on the HTML.
> APIMan (Angular UI) checks for a 401 response code and automatically refreshes the browser to combat this. However, I'm not sure if that's possible in this case. Our use of Errai's "Caller" pattern isn't kicking in for these errors (completely sidesteps the ErrorHandler), I'm guessing due to it being a lower level issue with the GWT marshaller.
> Idea: Have a pure Javascript loop "ping" the UI services and check the response.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 11 months