Internal server error with event logging
by Matthias Kesternich
Hello,
with event detail logging enabled I keep getting 500 Internal Server Error. There was also a post on this list in May detailing the same problem (see http://lists.jboss.org/pipermail/keycloak-dev/2018-May/010807.html ).
As outlined in the post the problematic piece of code is
@Column(name="DETAILS_JSON", length = 2550)
private String detailsJson;
This hardcodes length to 2550 and apparently some of my event details get bigger than that.
Any idea what I can do about this? Manually changing the database column could work, but I’m afraid a future keycloak db migration will badly interfere with this.
Is there any “official” way to override values like this? E.g. some configuration setting or JPA way to overwrite this?
Thanks,
-Matthias
5 years, 7 months
Access to EntityManager/KeycloakSession from a MessageDrivenBean inside Keycloak
by Edwin Steiner
Hello All
We would like to extended our Keycloak instance with a MessageDrivenBean for user synchronization. Inside the MessageDrivenBean we need access to the EntityManager for storing the imported users in the database.
@MessageDriven(name = "ImportUserMessageHandler", activationConfig = {
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
@ActivationConfigProperty(propertyName = "destination", propertyValue = “ImportQueue"),
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
@ApplicationScoped
public class ImportUserMessageHandler extends AbstractMessageDrivenBean {
@PersistenceContext(unitName="keycloak-default")
private EntityManager entityManager;
}
But the above code results in the following error message:
————————
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0041: Component class com.inventage.iam.import.ImportUserMessageHandler for component ImportUserMessageHandler has errors:
WFLYJPA0033: Can't find a persistence unit named keycloak-default in deployment "keycloak-spi.jar"
at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:157)
at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:186)
at org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:143)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
... 5 more
————————
Normally the EntityManager is gotten via keycloakSession.getProvider(JpaConnectionProvider.class).getEntityManager(), but in the MessageDrivenBean we have no access a KeycloakSession instance.
Is there an other way to get the EntityManager? Or can we get somehow a KeycloakSession instance inside the MessageDrivenBean?
Thanks
Edwin
5 years, 7 months
Keycloak & SAML & Workplace By Facebook
by Rémi GOYARD
Hi everyone,
I’m trying to configure an SAML client for my Realm to enable SSO authentication in Workplace By Facebook
Facebook ask for the following :
URL SAML -> I Use the url of the client auth
URI SAML emitter => I use the same as above
Certificate : I get Certificate from client / SAML Keys
Facebook give me :
Audience URL (I don’t know where to use)
URL SAML : This is the web root (Master SAML Processing URL)
URL ACS : (Assertion Consumer Service POST Binding URL )
When, in workplace, I clic on Test SSO, It open a popup, ask me to login, then redirect to an error “SSO Unauthenticated” (SAML response is not valid) …
I don’t know why and do not have more informations.
Does anyone had the same problem ?
Any ideas ?
Or even try to configure Workplace and Keycloak working together ?
Regards
Rémi
5 years, 7 months
Upgrade Documentation: Containers and Cross-Dc
by Hayden Fuss
Hello,
When going through the upgrade documentation, it was tailored towards very
mutable deployments of Keycloak on VMs. Will the docs soon describe
containerized deployments of Keycloak as well? Obviously, the config XML
changes won't be the issue, moreso just the deployment strategy.
The docs say
For standalone-high availability (HA) mode, all instances must be upgraded
> at the same time.
Which to me is a little vague, it almost sounds like you *have* to stop all
servers at the same time rather than in a rolling fashion. Does this mean
you can't deploy Keycloak with zero-downtime? Even in a containerized
environment which will more easily allow for rolling, blue/green, or canary
deployments?
For the cross-DC scenario thats even scarier since Keycloak would have to
be down in *all* DC's temporarily. Even if thats not the case, how does the
manual DB migration work, especially in the cross-DC case:
When you start the server with this configuration it checks if the database
> needs to be migrated. The required changes are written to an SQL file that
> you can review and manually run against the database
>
It sounds like you have to start the new version of the server to get the
migrations. What will the new version of the server do while the migrations
haven't been applied, will it still run or crash/return 5xxs since the
schema updates I would think it _requires_ don't exist?
Also this is in no way container feels friendly since you can get the
migrations off a container easily. The automated migrations seem like they
would require downtime too unless the changes are guaranteed to be
backwards compatible, but that contradicts "all instances must be upgraded
at the same time".
Also with the 4.4.0 release coming up, Infinispan will be upgraded a major
version that will likely be breaking release for those running the cross-DC
setup, or will they have the option to keep using Infinispan 8.2.8? Can we
expect lots of Infinispan upgrades in the future?
Sorry I know those are a lot of questions, thanks for any help clarifying
or providing past experiences with Keycloak upgrades.
Best,
Hayden
5 years, 7 months
JBoss EAP 7.1 RH-SSO 7.2 Rest Service Keycloak Bearer Only AuthenticatedActionsValve.invoke Policy enforcement is disabled 403 Forbidden
by Shawn Firth
My configuration is: JBoss EAP 7.1.4 RH-SSO 7.2.4 JDK 1.8.0u172 We have
built a Rest/JSON web service based on the
jboss-eap-quickstarts-7.1\contacts-jquerymobile example, without any of the
JavaScript GUI components, which works fine. We then attempted to secure
this Rest/JSON web service using the
redhat-sso-quickstarts-7.2.x\service-jee-jaxrs example for guidance, after
getting the service-jee-jaxrs example running locally. The Rest/JSON web
service is secured using keycloak, and access is bearer only. Here is the
web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<module-name>OurRestService</module-name>
<security-constraint>
<web-resource-collection>
<web-resource-name>All</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>mobilerole</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>KEYCLOAK</auth-method>
</login-config>
<security-role>
<role-name>mobilerole</role-name>
</security-role>
Here is the keycloak.json
{
"realm": "mobilerealm",
"bearer-only": true,
"auth-server-url": "blah blah localhost:8180/auth",
"ssl-required": "external",
"resource": "OurRestService",
"confidential-port": 0
}
Below is the JBoss server log output from an attempted GET using PostMan.
As you can see the bearer only token is successfully authenticated by SSO,
but the web service never fires, and PostMan gets a 403 Forbidden.
Please note the last 2 lines of the log with:
"*2018-08-31 11:42:57,025 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-4)
AuthenticatedActionsValve.invoke
http://localhost:8080/OurRestService/rest/contacts/
<http://localhost:8080/OurRestService/rest/contacts/>*
*2018-08-31 11:42:57,025 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-4) Policy
enforcement is disabled.*"
What am I missing?
2018-08-31 11:42:56,917 DEBUG [io.undertow.request.security] (default
task-4) Attempting to authenticate HttpServerExchange{ GET
/OurRestService/rest/contacts/ request
{Postman-Token=[cb7f2b96-ddb0-4490-8bdb-2ae110048b1c], Accept=[*/*],
cache-control=[no-cache], accept-encoding=[gzip, deflate],
User-Agent=[PostmanRuntime/7.2.0], Connection=[keep-alive],
Authorization=[Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJxSzJKWjUyVjFmU0pKRG82M0hmZHlJbjYyWERlX2hhSWhFMGV5ZXZkQlowIn0.eyJqdGkiOiI4MjNhYzk2Ni05Zjc0LTQ1ZjMtOWE4NC0wN2M2OGMwNDI5ODQiLCJleHAiOjE1MzU3MzA0NzEsIm5iZiI6MCwiaWF0IjoxNTM1NzMwMTcxLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvbW9iaWxlcmVhbG0iLCJhdWQiOiJhZG1pbi1jbGkiLCJzdWIiOiIyMThlYTcwNC0zYTdhLTQ3NjYtYTI1MS02OWQ5YWE4ZTc1ZmYiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhZG1pbi1jbGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIyNGUyYTQ5OC1jNjViLTRhOWEtODc0YS0yNGVkOTdjOWVjNmMiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVzb3VyY2VfYWNjZXNzIjp7fSwibmFtZSI6Ik1vYmlsZSBVc2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoibW9iaWxldXNlciIsImdpdmVuX25hbWUiOiJNb2JpbGUiLCJmYW1pbHlfbmFtZSI6IlVzZXIiLCJlbWFpbCI6InNoYXduLmZpcnRoQGdtYWlsLmNvbSJ9.jawXZlWhnKJCbCiqxk7jqNLPox8OAa2kD4upOaZdLEmkrMFMW1Gn193C1gJSdwwzQZtlmVLnWbIPhBLBUg_c_NCkeYhoAc2x5AffqOtPMDeHbcj06O_UOSzGIrsf86a1dOOMRP1B7fUtmve2xwbJqXC93j64t7uIU1ESnB8jr6qpwGnz2w_8wykkVqrKaeYaX2ZmlayLcz4dypxUgjSunmR2XLs2BJXURn1h2MTvQzSJLTTLDD0t7H1iVso_l6dYUgI27Pg1Ug-U2hLl8pu-iF82r4ARTgySIwucjWPNCiyWTNlkU2rclJ0tmcGU5LJ1PcOC3SYoiSZWsVXa0owHhA],
Content-Type=[application/json],
cookie=[JSESSIONID=rGEYK52-lB-f9KfOPcfAB9b6IXlKUIm8_9o1GkK6.sfirth],
Host=[localhost:8080]} response {Expires=[0], Cache-Control=[no-cache,
no-store, must-revalidate], X-Powered-By=[Undertow/1],
Server=[JBoss-EAP/7], Pragma=[no-cache]}}, authentication required: true
2018-08-31 11:42:56,917 DEBUG [io.undertow.request.security] (default
task-4) Authentication outcome was NOT_ATTEMPTED with method
io.undertow.security.impl.CachedAuthenticatedSessionMechanism@75a0aa11 for
HttpServerExchange{ GET /OurRestService/rest/contacts/ request
{Postman-Token=[cb7f2b96-ddb0-4490-8bdb-2ae110048b1c], Accept=[*/*],
cache-control=[no-cache], accept-encoding=[gzip, deflate],
User-Agent=[PostmanRuntime/7.2.0], Connection=[keep-alive],
Authorization=[Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJxSzJKWjUyVjFmU0pKRG82M0hmZHlJbjYyWERlX2hhSWhFMGV5ZXZkQlowIn0.eyJqdGkiOiI4MjNhYzk2Ni05Zjc0LTQ1ZjMtOWE4NC0wN2M2OGMwNDI5ODQiLCJleHAiOjE1MzU3MzA0NzEsIm5iZiI6MCwiaWF0IjoxNTM1NzMwMTcxLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvbW9iaWxlcmVhbG0iLCJhdWQiOiJhZG1pbi1jbGkiLCJzdWIiOiIyMThlYTcwNC0zYTdhLTQ3NjYtYTI1MS02OWQ5YWE4ZTc1ZmYiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhZG1pbi1jbGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIyNGUyYTQ5OC1jNjViLTRhOWEtODc0YS0yNGVkOTdjOWVjNmMiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVzb3VyY2VfYWNjZXNzIjp7fSwibmFtZSI6Ik1vYmlsZSBVc2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoibW9iaWxldXNlciIsImdpdmVuX25hbWUiOiJNb2JpbGUiLCJmYW1pbHlfbmFtZSI6IlVzZXIiLCJlbWFpbCI6InNoYXduLmZpcnRoQGdtYWlsLmNvbSJ9.jawXZlWhnKJCbCiqxk7jqNLPox8OAa2kD4upOaZdLEmkrMFMW1Gn193C1gJSdwwzQZtlmVLnWbIPhBLBUg_c_NCkeYhoAc2x5AffqOtPMDeHbcj06O_UOSzGIrsf86a1dOOMRP1B7fUtmve2xwbJqXC93j64t7uIU1ESnB8jr6qpwGnz2w_8wykkVqrKaeYaX2ZmlayLcz4dypxUgjSunmR2XLs2BJXURn1h2MTvQzSJLTTLDD0t7H1iVso_l6dYUgI27Pg1Ug-U2hLl8pu-iF82r4ARTgySIwucjWPNCiyWTNlkU2rclJ0tmcGU5LJ1PcOC3SYoiSZWsVXa0owHhA],
Content-Type=[application/json],
cookie=[JSESSIONID=rGEYK52-lB-f9KfOPcfAB9b6IXlKUIm8_9o1GkK6.sfirth],
Host=[localhost:8080]} response {Expires=[0], Cache-Control=[no-cache,
no-store, must-revalidate], X-Powered-By=[Undertow/1],
Server=[JBoss-EAP/7], Pragma=[no-cache]}}
2018-08-31 11:42:56,917 DEBUG
[org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-4)
Verifying access_token
2018-08-31 11:42:56,978 DEBUG
[org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager] (default
task-4) Get connection: {}->http://localhost:8180, timeout = 0
2018-08-31 11:42:56,979 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4) [{}->
http://localhost:8180] total kept alive: 0, total issued: 0, total
allocated: 0 out of 20
2018-08-31 11:42:56,979 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4) No free
connections [{}->http://localhost:8180][null]
2018-08-31 11:42:56,979 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4)
Available capacity: 20 out of 20 [{}->http://localhost:8180][null]
2018-08-31 11:42:56,979 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4) Creating
new connection [{}->http://localhost:8180]
2018-08-31 11:42:56,984 DEBUG
[org.apache.http.impl.conn.DefaultClientConnectionOperator] (default
task-4) Connecting to localhost:8180
2018-08-31 11:42:56,995 DEBUG
[org.apache.http.client.protocol.RequestAddCookies] (default task-4)
CookieSpec selected: compatibility
2018-08-31 11:42:56,995 DEBUG
[org.apache.http.client.protocol.RequestAuthCache] (default task-4) Auth
cache not set in the context
2018-08-31 11:42:56,995 DEBUG
[org.apache.http.client.protocol.RequestTargetAuthentication] (default
task-4) Target auth state: UNCHALLENGED
2018-08-31 11:42:56,996 DEBUG
[org.apache.http.client.protocol.RequestProxyAuthentication] (default
task-4) Proxy auth state: UNCHALLENGED
2018-08-31 11:42:56,996 DEBUG
[org.apache.http.impl.client.DefaultHttpClient] (default task-4) Attempt 1
to execute request
2018-08-31 11:42:56,996 DEBUG
[org.apache.http.impl.conn.DefaultClientConnection] (default task-4)
Sending request: GET /auth/realms/mobilerealm/protocol/openid-connect/certs
HTTP/1.1
2018-08-31 11:42:56,996 DEBUG [org.apache.http.wire] (default task-4) >>
"GET /auth/realms/mobilerealm/protocol/openid-connect/certs
HTTP/1.1[\r][\n]"
2018-08-31 11:42:56,997 DEBUG [org.apache.http.wire] (default task-4) >>
"Host: localhost:8180[\r][\n]"
2018-08-31 11:42:56,997 DEBUG [org.apache.http.wire] (default task-4) >>
"Connection: Keep-Alive[\r][\n]"
2018-08-31 11:42:56,997 DEBUG [org.apache.http.wire] (default task-4) >>
"[\r][\n]"
2018-08-31 11:42:56,997 DEBUG [org.apache.http.headers] (default task-4) >>
GET /auth/realms/mobilerealm/protocol/openid-connect/certs HTTP/1.1
2018-08-31 11:42:56,997 DEBUG [org.apache.http.headers] (default task-4) >>
Host: localhost:8180
2018-08-31 11:42:56,997 DEBUG [org.apache.http.headers] (default task-4) >>
Connection: Keep-Alive
2018-08-31 11:42:57,000 DEBUG [org.apache.http.wire] (default task-4) <<
"HTTP/1.1 200 OK[\r][\n]"
2018-08-31 11:42:57,001 DEBUG [org.apache.http.wire] (default task-4) <<
"Connection: keep-alive[\r][\n]"
2018-08-31 11:42:57,001 DEBUG [org.apache.http.wire] (default task-4) <<
"Cache-Control: no-cache[\r][\n]"
2018-08-31 11:42:57,001 DEBUG [org.apache.http.wire] (default task-4) <<
"Content-Type: application/json[\r][\n]"
2018-08-31 11:42:57,001 DEBUG [org.apache.http.wire] (default task-4) <<
"Content-Length: 462[\r][\n]"
2018-08-31 11:42:57,002 DEBUG [org.apache.http.wire] (default task-4) <<
"Date: Fri, 31 Aug 2018 15:42:57 GMT[\r][\n]"
2018-08-31 11:42:57,002 DEBUG [org.apache.http.wire] (default task-4) <<
"[\r][\n]"
2018-08-31 11:42:57,002 DEBUG
[org.apache.http.impl.conn.DefaultClientConnection] (default task-4)
Receiving response: HTTP/1.1 200 OK
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
HTTP/1.1 200 OK
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
Connection: keep-alive
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
Cache-Control: no-cache
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
Content-Type: application/json
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
Content-Length: 462
2018-08-31 11:42:57,002 DEBUG [org.apache.http.headers] (default task-4) <<
Date: Fri, 31 Aug 2018 15:42:57 GMT
2018-08-31 11:42:57,004 DEBUG
[org.apache.http.impl.client.DefaultHttpClient] (default task-4) Connection
can be kept alive indefinitely
2018-08-31 11:42:57,008 DEBUG [org.apache.http.wire] (default task-4) <<
"{"keys":[{"kid":"qK2JZ52V1fSJJDo63HfdyIn62XDe_haIhE0eyevdBZ0","kty":"RSA","alg":"RS256","use":"sig","n":"5dKNlsMOu2W6WB0X1G27PcqUoBLPzPUDtfQmA7uf0BaPSkYu7CnbUPdShrs09RGQM6tWWL_6_qiacFi9jBgyEAhT9MhQ-rgkPe0YpdyQtVqznZH5CHkaAq9fTxwmEUXUZvRWuP4cAF7Pi5RfVgOIRflI-AgGyiH-ygdinRQx10nr-m7Us2seCM8QB5zjsKz3YLNdnk_bmvc6axhPpZAAlUCaAMM-j0Edc9CR7NDw09aUIKGED8wWdmxxdteqfPVjKiIlFjg1-QiroEH2PnNOqFTn2UKX6imOJmEc9XlJCsthlEHz-1Pqz23imiLkk-n2S3CJVyvnnI-OvUYaaOF6_w","e":"AQAB"}]}"
2018-08-31 11:42:57,010 DEBUG
[org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager] (default
task-4) Released connection is reusable.
2018-08-31 11:42:57,010 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4)
Releasing connection [{}->http://localhost:8180][null]
2018-08-31 11:42:57,010 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4) Pooling
connection [{}->http://localhost:8180][null]; keep alive indefinitely
2018-08-31 11:42:57,011 DEBUG
[org.apache.http.impl.conn.tsccm.ConnPoolByRoute] (default task-4)
Notifying no-one, there are no waiting threads
2018-08-31 11:42:57,012 DEBUG
[org.keycloak.adapters.rotation.JWKPublicKeyLocator] (default task-4) Realm
public keys successfully retrieved for client OurRestService. New kids:
[qK2JZ52V1fSJJDo63HfdyIn62XDe_haIhE0eyevdBZ0]
2018-08-31 11:42:57,013 DEBUG
[org.keycloak.adapters.BearerTokenRequestAuthenticator] (default task-4)
successful authorized
2018-08-31 11:42:57,015 DEBUG [io.undertow.request.security] (default
task-4) Authenticated as 218ea704-3a7a-4766-a251-69d9aa8e75ff, roles []
2018-08-31 11:42:57,023 DEBUG
[org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default
task-4) propagate security context to wildfly
2018-08-31 11:42:57,024 DEBUG [org.keycloak.adapters.RequestAuthenticator]
(default task-4) User '218ea704-3a7a-4766-a251-69d9aa8e75ff' invoking '
http://localhost:8080/OurRestService/rest/contacts/' on client
'OurRestService'
2018-08-31 11:42:57,024 DEBUG [org.keycloak.adapters.RequestAuthenticator]
(default task-4) Bearer AUTHENTICATED
2018-08-31 11:42:57,024 DEBUG [io.undertow.request.security] (default
task-4) Authentication outcome was AUTHENTICATED with method
org.keycloak.adapters.wildfly.WildflyAuthenticationMechanism@63d7bad9 for
HttpServerExchange{ GET /OurRestService/rest/contacts/ request
{Postman-Token=[cb7f2b96-ddb0-4490-8bdb-2ae110048b1c], Accept=[*/*],
cache-control=[no-cache], accept-encoding=[gzip, deflate],
User-Agent=[PostmanRuntime/7.2.0], Connection=[keep-alive],
Authorization=[Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJxSzJKWjUyVjFmU0pKRG82M0hmZHlJbjYyWERlX2hhSWhFMGV5ZXZkQlowIn0.eyJqdGkiOiI4MjNhYzk2Ni05Zjc0LTQ1ZjMtOWE4NC0wN2M2OGMwNDI5ODQiLCJleHAiOjE1MzU3MzA0NzEsIm5iZiI6MCwiaWF0IjoxNTM1NzMwMTcxLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvbW9iaWxlcmVhbG0iLCJhdWQiOiJhZG1pbi1jbGkiLCJzdWIiOiIyMThlYTcwNC0zYTdhLTQ3NjYtYTI1MS02OWQ5YWE4ZTc1ZmYiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhZG1pbi1jbGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIyNGUyYTQ5OC1jNjViLTRhOWEtODc0YS0yNGVkOTdjOWVjNmMiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVzb3VyY2VfYWNjZXNzIjp7fSwibmFtZSI6Ik1vYmlsZSBVc2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoibW9iaWxldXNlciIsImdpdmVuX25hbWUiOiJNb2JpbGUiLCJmYW1pbHlfbmFtZSI6IlVzZXIiLCJlbWFpbCI6InNoYXduLmZpcnRoQGdtYWlsLmNvbSJ9.jawXZlWhnKJCbCiqxk7jqNLPox8OAa2kD4upOaZdLEmkrMFMW1Gn193C1gJSdwwzQZtlmVLnWbIPhBLBUg_c_NCkeYhoAc2x5AffqOtPMDeHbcj06O_UOSzGIrsf86a1dOOMRP1B7fUtmve2xwbJqXC93j64t7uIU1ESnB8jr6qpwGnz2w_8wykkVqrKaeYaX2ZmlayLcz4dypxUgjSunmR2XLs2BJXURn1h2MTvQzSJLTTLDD0t7H1iVso_l6dYUgI27Pg1Ug-U2hLl8pu-iF82r4ARTgySIwucjWPNCiyWTNlkU2rclJ0tmcGU5LJ1PcOC3SYoiSZWsVXa0owHhA],
Content-Type=[application/json],
cookie=[JSESSIONID=rGEYK52-lB-f9KfOPcfAB9b6IXlKUIm8_9o1GkK6.sfirth],
Host=[localhost:8080]} response {Expires=[0], Cache-Control=[no-cache,
no-store, must-revalidate], X-Powered-By=[Undertow/1],
Server=[JBoss-EAP/7], Pragma=[no-cache]}}
2018-08-31 11:42:57,024 DEBUG [io.undertow.request.security] (default
task-4) Authentication result was AUTHENTICATED for HttpServerExchange{ GET
/OurRestService/rest/contacts/ request
{Postman-Token=[cb7f2b96-ddb0-4490-8bdb-2ae110048b1c], Accept=[*/*],
cache-control=[no-cache], accept-encoding=[gzip, deflate],
User-Agent=[PostmanRuntime/7.2.0], Connection=[keep-alive],
Authorization=[Bearer
eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJxSzJKWjUyVjFmU0pKRG82M0hmZHlJbjYyWERlX2hhSWhFMGV5ZXZkQlowIn0.eyJqdGkiOiI4MjNhYzk2Ni05Zjc0LTQ1ZjMtOWE4NC0wN2M2OGMwNDI5ODQiLCJleHAiOjE1MzU3MzA0NzEsIm5iZiI6MCwiaWF0IjoxNTM1NzMwMTcxLCJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjgxODAvYXV0aC9yZWFsbXMvbW9iaWxlcmVhbG0iLCJhdWQiOiJhZG1pbi1jbGkiLCJzdWIiOiIyMThlYTcwNC0zYTdhLTQ3NjYtYTI1MS02OWQ5YWE4ZTc1ZmYiLCJ0eXAiOiJCZWFyZXIiLCJhenAiOiJhZG1pbi1jbGkiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiIyNGUyYTQ5OC1jNjViLTRhOWEtODc0YS0yNGVkOTdjOWVjNmMiLCJhY3IiOiIxIiwiYWxsb3dlZC1vcmlnaW5zIjpbXSwicmVzb3VyY2VfYWNjZXNzIjp7fSwibmFtZSI6Ik1vYmlsZSBVc2VyIiwicHJlZmVycmVkX3VzZXJuYW1lIjoibW9iaWxldXNlciIsImdpdmVuX25hbWUiOiJNb2JpbGUiLCJmYW1pbHlfbmFtZSI6IlVzZXIiLCJlbWFpbCI6InNoYXduLmZpcnRoQGdtYWlsLmNvbSJ9.jawXZlWhnKJCbCiqxk7jqNLPox8OAa2kD4upOaZdLEmkrMFMW1Gn193C1gJSdwwzQZtlmVLnWbIPhBLBUg_c_NCkeYhoAc2x5AffqOtPMDeHbcj06O_UOSzGIrsf86a1dOOMRP1B7fUtmve2xwbJqXC93j64t7uIU1ESnB8jr6qpwGnz2w_8wykkVqrKaeYaX2ZmlayLcz4dypxUgjSunmR2XLs2BJXURn1h2MTvQzSJLTTLDD0t7H1iVso_l6dYUgI27Pg1Ug-U2hLl8pu-iF82r4ARTgySIwucjWPNCiyWTNlkU2rclJ0tmcGU5LJ1PcOC3SYoiSZWsVXa0owHhA],
Content-Type=[application/json],
cookie=[JSESSIONID=rGEYK52-lB-f9KfOPcfAB9b6IXlKUIm8_9o1GkK6.sfirth],
Host=[localhost:8080]} response {Expires=[0], Cache-Control=[no-cache,
no-store, must-revalidate], X-Powered-By=[Undertow/1],
Server=[JBoss-EAP/7], Pragma=[no-cache]}}
*2018-08-31 11:42:57,025 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-4)
AuthenticatedActionsValve.invoke
http://localhost:8080/OurRestService/rest/contacts/
<http://localhost:8080/OurRestService/rest/contacts/>*
*2018-08-31 11:42:57,025 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-4) Policy
enforcement is disabled.*
5 years, 7 months
login via curl
by Ronald Demneri
Greetings everyone,
I am testing the possibility to login via curl to the account client in my test realm and then use the tokens to access another client. I have tried this:
curl -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-H "cache-control: no-cache" \
-d "grant_type=password&scope=openid&client_id=account&username=test1&password=1234t1" \
"http://keycloak:8080/auth/realms/test /protocol/openid-connect/token" \
-v
But it gives me:
* upload completely sent off: 81 out of 81 bytes
< HTTP/1.1 400 Bad Request
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 91
What am I doing wrong and apologies if this question has been asked before.
Keycloak version is 4.1.0.Final
Ronald
5 years, 7 months
Re: [keycloak-user] TimeoutException: Replication timeout
by Piotr Wojcieszonek
This is Ubuntu 16.04 without SELinux.
> Wiadomość napisana przez Rafael Weingärtner <rafaelweingartner(a)gmail.com> w dniu 31.08.2018, o godz. 12:06:
>
> Then, there is only one things left in my mind. Did you configure SElinux?
>
> On Fri, Aug 31, 2018 at 7:04 AM, Piotr Wojcieszonek <p.wojcieszonek(a)bosmanager.com <mailto:p.wojcieszonek@bosmanager.com>> wrote:
> No, there is no firewall on host and both of them are in the same vlan.
>
>
>> Wiadomość napisana przez Rafael Weingärtner <rafaelweingartner(a)gmail.com <mailto:rafaelweingartner@gmail.com>> w dniu 31.08.2018, o godz. 12:00:
>>
>> Your cluster is being created. Everything seems fine there. I had a problem once when the cluster was not being formed due to firewall problems.
>> Is your firewall activated?
>>
>> On Fri, Aug 31, 2018 at 6:56 AM, Piotr Wojcieszonek <p.wojcieszonek(a)bosmanager.com <mailto:p.wojcieszonek@bosmanager.com>> wrote:
>>
>> 2018-08-30 00:07:43,048 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|0] (1) [authservice1]
>> 2018-08-30 00:07:43,049 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel ejb: [authservice1|0] (1) [authservice1]
>> 2018-08-30 00:07:43,048 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [authservice1|0] (1) [authservice1]
>> 2018-08-30 00:07:43,049 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [authservice1|0] (1) [authservice1]
>> 2018-08-30 00:07:43,048 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [authservice1|0] (1) [authservice1]
>> 2018-08-30 00:07:45,757 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|1] (2) [authservice1, authservice2]
>> 2018-08-30 00:07:45,758 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|1] (2) [authservice1, authservice2]
>> 2018-08-30 00:07:45,763 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|1] (2) [authservice1, authservice2]
>> 2018-08-30 00:07:45,779 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|1] (2) [authservice1, authservice2]
>> 2018-08-30 00:07:45,783 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|1] (2) [authservice1, authservice2]
>> 2018-08-30 00:39:50,071 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 00:39:50,071 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 00:39:50,071 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 00:39:50,071 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 00:39:50,078 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 19:41:38,553 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 19:41:43,562 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 19:41:43,563 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 19:41:43,563 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 19:41:43,563 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 19:41:43,563 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 21:16:23,261 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 21:16:23,264 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 21:16:23,330 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 21:16:23,330 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 21:16:23,344 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-2) ISPN000094: Received new cluster view for channel ejb: [authservice1|2] (1) [authservice1]
>> 2018-08-30 21:17:36,994 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-2) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 21:17:36,995 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 21:17:36,994 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 21:17:36,995 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>> 2018-08-30 21:17:36,995 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view for channel ejb: [authservice2|1] (2) [authservice2, authservice1]
>>
>>
>>> Wiadomość napisana przez Rafael Weingärtner <rafaelweingartner(a)gmail.com <mailto:rafaelweingartner@gmail.com>> w dniu 31.08.2018, o godz. 11:52:
>>>
>>> Can you check if your cluster if being formed? You can grep the word "view" in Keycloak's logs.
>>>
>>> On Fri, Aug 31, 2018 at 3:16 AM, Piotr Wojcieszonek <p.wojcieszonek(a)bosmanager.com <mailto:p.wojcieszonek@bosmanager.com>> wrote:
>>> Yes I did:
>>> <distributed-cache name="sessions" mode="SYNC" owners="2"/>
>>> <distributed-cache name="authenticationSessions" mode="SYNC" owners="2"/>
>>> <distributed-cache name="offlineSessions" mode="SYNC" owners="2"/>
>>> <distributed-cache name="clientSessions" mode="SYNC" owners="2"/>
>>> <distributed-cache name="offlineClientSessions" mode="SYNC" owners="2"/>
>>> <distributed-cache name="loginFailures" mode="SYNC" owners="2”/>
>>>
>>> I have two node cluster.
>>>
>>>
>>>
>>>> Wiadomość napisana przez Rafael Weingärtner <rafaelweingartner(a)gmail.com <mailto:rafaelweingartner@gmail.com>> w dniu 31.08.2018, o godz. 03:01:
>>>>
>>>> Did you configure the "owners" parameter in the standalone-ha.xml with a value bigger than 1?
>>>>
>>>> On Thu, Aug 30, 2018 at 5:06 PM, Piotr Wojcieszonek <p.wojcieszonek(a)bosmanager.com <mailto:p.wojcieszonek@bosmanager.com>> wrote:
>>>> Hi,
>>>> I have problem with standalone cluster. After cluster start working it begin to print that kind of information to log file:
>>>>
>>>> 2018-08-30 22:04:33,725 WARN [org.infinispan.expiration.impl.ClusterExpirationManager] (expiration-thread--p22-t1) ISPN000026: Caught exception purging data container!: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
>>>> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>>>> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>>>> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>>>> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>>
>>>> 2018-08-30 22:04:39,966 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Timer-2) ISPN000136: Error executing command PutKeyValueCommand, writing keys [task::ClearExpiredClientInitialAccessTokens]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
>>>> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>>>> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>>>> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>>>> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>>
>>>> 2018-08-30 22:04:52,605 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Timer-2) ISPN000136: Error executing command PutKeyValueCommand, writing keys [task::ClearExpiredClientInitialAccessTokens]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
>>>> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
>>>> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
>>>> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
>>>> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
>>>> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
>>>> at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
>>>> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>>>> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>> at java.lang.Thread.run(Thread.java:748)
>>>>
>>>> And in time it start to work very slow.
>>>> What can by a reason for that?
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>
>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>
>>
>>
>>
>> --
>> Rafael Weingärtner
>
>
>
>
> --
> Rafael Weingärtner
5 years, 7 months
TimeoutException: Replication timeout
by Piotr Wojcieszonek
Hi,
I have problem with standalone cluster. After cluster start working it begin to print that kind of information to log file:
2018-08-30 22:04:33,725 WARN [org.infinispan.expiration.impl.ClusterExpirationManager] (expiration-thread--p22-t1) ISPN000026: Caught exception purging data container!: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-08-30 22:04:39,966 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Timer-2) ISPN000136: Error executing command PutKeyValueCommand, writing keys [task::ClearExpiredClientInitialAccessTokens]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
2018-08-30 22:04:52,605 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (Timer-2) ISPN000136: Error executing command PutKeyValueCommand, writing keys [task::ClearExpiredClientInitialAccessTokens]: org.infinispan.util.concurrent.TimeoutException: Replication timeout for authservice1
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:827)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$0(JGroupsTransport.java:628)
at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:46)
at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
And in time it start to work very slow.
What can by a reason for that?
5 years, 7 months
authenticate users programmatically with Java
by Erik G. Haugen
I see there an extensive Java API for use with Keycloak, but there is
little documentation.
How can I authenticate users programmatically with Java?
In my Java program, I will have a userid and password. How do I
authenticate the user and get a valid token with Java?
Also, is there any documentation for basic usage of the Java API?
Thank you,
Erik
5 years, 7 months
Differnentiate Login Error for Disabled Account (Version 3.4.3 Final)
by Patrick Bucher
When a disabled user tries to login, he gets an error 400 Bad Request (error: "invalid_grant", error_description: "Account disabled"). However, in my project, there are multiple reasons for a user to be disabled, which are distinguishable by certain attributes I set to the user.
My goal is to create a Keycloak extension to customize the response based on those attributes, so that a different error message can be shown to the user. Providing a different value error_description would be a solution.
My question is: Is it possible to intercept that error message before it is sent to the client, and if so, what kind of SPI do I need to write to handle that?
I am using Keycloak version 3.4.3 Final.
Regards,
Patrick Bucher
5 years, 7 months
