[keycloak-dev] sticky sessions

[Marek Posolda]

How about protocolMappers? If there were no changes to user, the 
refreshToken endpoint won't call protocolMappers but just use user data 
from previously saved cached token from userSession?

Marek


On 02/12/15 19:25, Stian Thorgersen wrote:
> We don't replicate the session. It's a distributed cache so it's 
> fetched internally from the correct node.
>
> For refresh token maybe we could update the user session for a user 
> that they need to be checked against the user changes?
>
> On 2 December 2015 at 18:58, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 12/2/2015 12:54 PM, Bill Burke wrote:
>     >
>     >
>     > On 12/2/2015 12:46 PM, Stian Thorgersen wrote:
>     >> Wonder if we could do something similar with code 2 token.
>     Could we not
>     >> set a cookie there as well? Then at most there would be two
>     nodes for
>     >> one user.
>     >>
>     >> Alternative is to update code 2 token so it doesn't require the
>     user
>     >> model. That would be more elegant. We could do that by making
>     sure user
>     >> sessions are updated when required if user model changes.
>     >>
>     >
>     > You could optimistically create the token and store it within
>     the client
>     > session.  But then your overhead is in replication? Then again is
>     > replicating a few kilobytes that big of a deal?
>     >
>
>     Answering my own question...It probabbly isn't a big deal as you are
>     already replicating the client session anyways.
>
>     Doesn't help refresh token though.  Refresh token needs to verify the
>     user is still enabled.
>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151203/41c64364/attachment-0001.html