guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ggagnon <>
Subject In-Context Launch and Caching
Date Wed, 21 Mar 2018 19:47:43 GMT
Trying to setup Guacamole to support the invocation of connections in-context
(target node as URL parameter).   I've set up my own authentication plugin
as per documentation (based on SimpleAuthenticationProvider) and I'm
successfully activating it as part of the docker container.
That plugin simply validates the user (against our own store) and returns a
new Connection configuration for the given parameter (again, using
information from our own store). [i.e. the only active plugin is ours,
user/connection data is not in files/mysql). 
No username/password is provided with the connection configuration (the user
needs to log into the target explicitly) and that's OK for now.  The
connection configuration only gets the IP, Port, and Protocol information.
The problem I'm having is that when I test/invoke the URL for, say, node X
in a browser (Chrome), I get my terminal window for node X.  However, if I
then do the same for node Y, I still get the terminal connecting to node X.  
It's not clear at all where the issue lies.
There's some signs of browser caching problems but I'm not convinced (the
Chrome Dev/Network tool does seem to show that the Y URL is sent down but it
gets muddled through the redirections...)
On the server logs, the puzzling thing is that on the second call, I see no
trace of my authentication plugin being invoked at all.   Instead, the logs
show that the user is just immediately connected to the previous target...

18:57:18.014 [http-nio-8080-exec-4] INFO  o.a.g.environment.LocalEnvironment
- GUACAMOLE_HOME is "/root/.guacamole".
18:57:18.057 [http-nio-8080-exec-4] INFO  o.a.g.tunnel.TunnelRequestService
- User "f9cf9ef2-670f-4801-b78c-3b49a2162a35" connected to connection "X".

How can I get all requests to be vetted through the my plugin'
It's as if there is some caching and I thought that overriding some
additional calls like authenticateUser might do the work but it's not
obvious with many needed bits in SimpleAuthenticationProvider (like
SimpleAuthenticatedUser) being defined as private...  

Thanks for any help.

Sent from:

View raw message