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
authenticatedUser,
Credentials
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:
getAuthorizedConfigurations
-> updateAuthenticatedUser (-> getAuthorizedConfigurations)
-> updateUserContext (really does nothing)
and on subsequent calles whilst the cookie is there:
updateAuthenticatedUser (-> getAuthorizedConfiguration)
-> updateUserContext (->
updateAuthenticatedUser
->
getAuthorizedConfigurations
->
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
this...
--
Sent from:
http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/
