>From what I can tell we don't have a filter adding caching to HTTP302 calls. I did not update the distributed-cache settings to have more then one owner. I made the update after the fact and restarted keycloak. This did not fix the problem and I still end up with the same stracktraces I sent out in the original email. This setting is a bit worrying to me as I would have to hardcode the cache to distribute to a specific number of nodes rather then distribute the cache to all nodes within the cluster. We will be doing doing elastic load balancing to dynamically increase and decrease the number of keycloak nodes into the cluster. It seems once we have ended up in this state it is impossible to undo? There might have been something persisted to the database that made this issue permanent? We definitely had keycloak 1.9.1 working before we switched from running a single instance without HA mode to HA mode. HA mode did appear to work for awhile until we had terminated one of the nodes in the cluster. We enabled HA mode based on some comments made by others on the user distribution list. I believe the thread was on http://lists.jboss.org/pipermail/keycloak-user/2016-April/005667.html . It was on the same version of keycloak as us but was running on ECS (docker) instead of EC2. Preferably I would like to turn the cache off entirely as we are not currently restricted to performance issues right now. Is there a way to completely turn off cache so I could run multiple keycloak instances without needing to run in HA mode? I did see some keycloak PR's that had added sections to the keycloak-server.json which set session cache to true/enabled. Couldn't I simply set it to false/disabled to achieve the desired result? Thanks, Jesse > Date: Wed, 13 Apr 2016 23:13:46 -0400 > From: Bill Burke <bburke(a)redhat.com&gt; > Subject: Re: [keycloak-user] Login works sometimes, sometimes doesn't > To: keycloak-user(a)lists.jboss.org > Message-ID: <570F0AEA.9010102(a)redhat.com&gt; > Content-Type: text/plain; charset=windows-1252; format=flowed > > These problems only happen when a cluster node dies? If so: > > How are you setting up the distributed cache for user sessions? If you > have only 1 owner, then the session is only replicated on one node. > This is the default behavior. > > <distributed-cache name="sessions" mode="SYNC" owners="1"/> > > 302 redirects should not be cached by the browser unless a Cache-Control > header is set. Do you have a filter doing this? > > http://stackoverflow.com/questions/12212839/how-long-is-a-302-redirect-sa... > > > > On 4/13/2016 9:53 PM, Jesse Chahal wrote: >> Hi, >> >> So it looks like the previous fix to the logout URL did the trick. >> I've now run into a much harder to solve problem (and harder to >> describe). We are inconsistently able to login to our client >> applications using keycloak for authentication. Trying the same >> username+password has about an 80% chance of logging you in correctly. >> It has a 15% chance of logging you in correctly if a keycloak node >> within a keycloak cluster dies. I made up the %'s but its based on >> what we are observing. So a user is actually able to login in the >> sense of putting in a username+password and getting redirected to the >> client applications, after that things may or may not go wrong. Often >> times they will access the client application with the correct role >> and everything will work ok. Sometimes though if something goes wrong >> they will be redirected back to the client and will not be able to >> access the client correctly. The below stacktraces usually show up in >> those cases. I think it might be related to keycloak cache + browser >> cache having weird issues as the only way to I've seen to resolve this >> issues is to destroy the session cache within keycloak and get rid of >> the browser cache (browser cache is more of a fault of the client app >> probably). Even with this it can take multiple attempts before a user >> regains the ability to go to the keycloak admin page and still may or >> may not lead to a successful redirect to the client with a correctly >> authenticated account (could start this whole weird loop again with >> the stracktraces below). I don't know if anyone has come into an issue >> like this. I was also hoping to find examples of client applications >> that have their own accounts which somehow get mapped to keycloak >> accounts but I haven't seen any. >> >> >> Environment >> ------------------------ >> - keycloak 1.9.1.Final >> - running using standalone-HA.xml >> - using JGroups+JDBC_Ping >> - postgres database >> - on AWS >> - some global roles (set on user accounts) >> >> Client >> ------------ >> - running on Wildfly10 >> - using keycloak subsystem >> - client protocol = openid-connect >> - access type = confidential >> - standard flow enabled >> - client authenticator = client id and secret >> >> >> Keycloak 1.9.1 server error >> ------------------------------------------- >> 2016-04-14 01:20:11,112 WARN [org.keycloak.events] (default task-17) >> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890, >> clientId=some_wildfly_client, userId=null, ipAddress=123.456.789.0, >> error=invalid_code, grant_type=authorization_code, >> code_id=b2744ba1-7f74-4849-8077-b17659af3095, >> client_auth_method=client-secret >> 2016-04-14 01:29:27,402 WARN [org.keycloak.events] (default task-2) >> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890, clientId= >> some_wildfly_client, userId=null, ipAddress=123.456.789.0, >> error=invalid_code, grant_type=authorization_code, >> code_id=58a57076-1f8e-404e-813b-13c31abe8efb, >> client_auth_method=client-secret >> 2016-04-14 01:29:27,402 WARN [org.keycloak.events] (default task-2) >> type=CODE_TO_TOKEN_ERROR, realmId=1234-5678-9012-3456-7890, clientId= >> some_wildfly_client, userId=null, ipAddress=123.456.789.0, >> error=invalid_code, grant_type=authorization_code, >> code_id=58a57076-1f8e-404e-813b-13c31abe8efb, >> client_auth_method=client-secret >> >> >> >> Wildfly 10 client server error: >> ----------------------------------------- >> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-13) [gwt_pc3q14cr_101 blah(a)example.com ] failed to turn >> code into token >> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-13) [gwt_pc3q14cr_101 blah(a)example.com ] status from >> server: 400 >> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-13) [gwt_pc3q14cr_101 blah(a)example.com ] >> {"error_description":"Code not found","error":"invalid_grant"} _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user