guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ggagnon <>
Subject Re: In-Context Launch and Caching
Date Thu, 22 Mar 2018 14:11:27 GMT
Actually, I may have just found a way I think... 
In my auth provider (derived from SimpleAuthenticationProvider), I just
overrode updateAuthenticatedUser() and updateUserContext().  The Simple
class' implementation simply returns the same user and context, mine force
the re-authentication:
    public AuthenticatedUser updateAuthenticatedUser(AuthenticatedUser
credentials) throws GuacamoleException {
        return authenticateUser(credentials);

    public UserContext updateUserContext(UserContext context,
AuthenticatedUser authorizedUser, Credentials credentials) throws
GuacamoleException {
        return getUserContext(authorizedUser);

However now, earch URL results in 2/3 runs at my authentication
(getAuthorizedConfigurations ) as the update calls seem to be invoked after
the valid calls:
The first time around for a user:
      -> updateAuthenticatedUser (-> getAuthorizedConfigurations) 
      -> updateUserContext (really does nothing)
and on subsequent calles whilst the cookie is there:
   updateAuthenticatedUser (-> getAuthorizedConfiguration) 
                                        -> updateUserContext (->

nearly recursive, but not quite...   The end result is ok, I get 2 different
connections to the 2 different targets, however, I need to figure out how to
safely avoid these redundant calls...

As for the memory/accumulation issue I raise, in
AuthenticationService.authenticate, I see that tokenSessionMap is populated
with information for each session.   However, it's not clear when those are
removed from the map.  I think I deduce from a rest API call
(Administration?) And there's another case upon an unclear exception but
there's limits to how IntelliJ will let me traceback and reverse engineer

Sent from:

View raw message