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