On Thu, Mar 5, 2026 at 11:47 PM Andrew Neugarten <[email protected]> wrote: > > Hello, > > I have recently installed Guacamole and Guacd (with a PostgreSQL database for > authentication/ authorization), and I have a question about shared sessions. > > From what I can tell, each time a user logs into the Guacamole web interface > and tries to access a VNC screen, a new connection from guacd to the VNC > server is established. However, when a session is shared via a link, guacd > does not establish an additional connection to the VNC.
Yes, this is correct, and the expected behavior from the interface. > > In my use case, I have limited bandwidth to VNC servers that several users > need to be able to view (read-only) simultaneously. Is it possible to > configure Guacamole so that when a user attempts to open a new VNC screen > from the web interface guacamole checks to see if there is already a > connection to that VNC (i.e., someone else is already connected to it). > Then, if a connection exists the user should just join a shared session and > only create a new connection to the VNC if none exists? Of course, it would > also be necessary for the connection to remain until all users who are using > it have disconnected (not only the one who created the connection). It is currently not possible to do this in Guacamole without making modifications to the code - using the Connection Sharing feature is the way this is designed to be used in the current implementation. > > If Guacamole can't do this, how would one start to implement it? Without digging into the code right now, there are a few ways that you could do this: * Modify the Java code that handles the connection logic and have it check for an existing connection, first, and then add the user to that connection, rather than establishing a new connection. Since you're using the JDBC module, so this would likely be implemented somewhere in either the connection or tunnel classes: https://github.com/apache/guacamole-client/tree/main/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/connection https://github.com/apache/guacamole-client/tree/main/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/tunnel * Rather than modifying the existing code, write an extension that decorates the existing ones and that allows for adding this functionality to existing connections. There are existing extensions that use this decoration model to provide additional functionality on top of the more core modules (JDBC) - for example, the TOTP module decorates existing users to provide multi-factor authentication, and the Restriction module allows for adding data/time and source address restrictions for users, user groups, connections, and connection groups. I _think_ that what you're trying to accomplish could be done by implementing a Connection type that wraps an existing connection, and overrides the connect() method of that class to redirect users to an existing active connection rather than establishing a new connection. Again, haven't looked closely, but I think it would work :-). * Modify the web application code (AngularJS, and possibly some Java) such that, when a connection is active, the link that other users are presented with is the link to the active connection rather than the link to establish a new connection. The down-side to this route would be that you could end up with some race-like conditions - if two users have the Guacamole Home page opened, User One starts a session, then two wouldn't necessarily see this change until refreshing the home page, and might end up with another session. This would take place somewhere in the main guacamole web application code: https://github.com/apache/guacamole-client/tree/main/guacamole/src/main Sorry these answers aren't more specific - I was leaning toward giving an answer rather than a complete answer, so it's just a couple of suggestions to where to start looking. Having broadly answered those questions, I have to caution a bit that you think through your requirements and use-case very, very carefully. I see two pretty glaring issues with the approach you're trying to take that are worth some careful consideration. It's possible you've already thought through these in your use case, but I still have to throw them out there: * The changes that I have described broadly above would need to be carefully implemented so that the system does not expose confidential information to other users. I understand that your use-case involves read-only access to VNC servers; however, if you do not put some other guard rails or restrictions in place, and the system is currently or will be used in the future for other users/connections of another type (RDP sessions, interactiving VNC sessions, etc.), you could expose sensitive information (credentials or PII), embarrassing information (personal conversations, web site content, etc.) or provide unauthorized access to data for certain users. The consequences of this could be far-reaching. * A little less risky, but still something that I think worth mentioning, is that you can introduce random or unexpected behavior into the system that confuses users. Again, I understand that your current use-case is for read-only connections to VNC servers, but, if those VNC servers require authentication, then a user may get prompted once, but not other times. Or, again, if the system is used for connections other than those read-only VNC sessions, users could be confused by randomly being connected to an existing session versus getting a brand-new, blank desktop connection. So, again, I think I understand that these items would not be a problem in your current use-case, just be careful that the changes you make combined with the system being drafted into other uses may have serious consequences. > > I apologize if this is not the correct place for this post. I am new to > Guacamole/ Guacd and would gladly appreciate any advice that could be shared. > This is definitely the correct place - please feel free to post back with any additional questions or concerns or clarification you need. -Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
