[keycloak-user] Login works sometimes, sometimes doesn't

Fri Apr 15 01:43:17 EDT 2016

You can disable the invalidation caches for realm and user data, but the
user session caches are still needed.

On 15 April 2016 at 02:31, Jesse Chahal <jessec at dnbcloud.com> wrote:

> >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 at redhat.com>
> > Subject: Re: [keycloak-user] Login works sometimes, sometimes doesn't
> > To: keycloak-user at lists.jboss.org
> > Message-ID: <570F0AEA.9010102 at redhat.com>
> > 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-saved-in-browser
> >
> >
> >
> > 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 at example.com ] failed to turn
> >> code into token
> >> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
> >> (default task-13) [gwt_pc3q14cr_101 blah at example.com ] status from
> >> server: 400
> >> 01:29:27,410 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
> >> (default task-13) [gwt_pc3q14cr_101 blah at example.com ]
> >> {"error_description":"Code not found","error":"invalid_grant"}
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160415/2d652203/attachment-0001.html 