Thanks Nick. When I imported the jdbc jar as a dependency, everything compiled, but then at runtime if complained that the objects were not the same (I can't remember exactly what the error was now, and have removed all the jars and dependencies, thinking it wasn't going to help us).
I actually spent today going through that chain you suggested all the way to the ActiveConnection, and the only way I could get the class to return anything was by giving the user group admin rights. I'm not sure what specific permission the group would need to be able to read that connection information, and since our users aren't in the jdbc set up, the only options we have are for the group: [image: image.png] We don't really want our users to be able to do any of those things, but otherwise the calls to getActiveConnectionDirectory() just return null. Our requirement isn't really anything to do with authentication, which is possibly why this seems harder than it should be. I'd really hoped the event listener system would give us a way to get from the TunnelConectEvent the information about _where_ the tunnel was connecting to—all we need to do is fire off a REST-type request to our own service, passing the credentials of the user who is connecting. In our UserContext implementation, I'd been able to finally (with Admin permission above) been able to get the connection id using: Directory<ActiveConnection> activeConnectionDirectory = userContext.getActiveConnectionDirectory(); ActiveConnection ac = activeConnectionDirectory.get(tunnel.getUUID().toString()); String id = ac.getConnectionIdentifier(); Using a REST client, I'd been able to get the name of the target host from https://localhost/api/session/data/postgresql/connections/1 (or whatever connection id was). But I can't yet see how to do that REST request 'internally' from the classes available. And even then, the connection is defined (in jdbc) by IP address, and that's really what we want, rather than just the connection name. We can make that work using local DNS, but if the tunnel could just tell us the IP of where it was connected to, that would be everything we'd need. Is that something you'd consider including in a future release, if I can work out where / how to add it? Endpoint configuration on connection doesn't seem like such an outlandish thing to want to do—maybe we're going about this wrong? Many thanks, David On Thu, 1 Aug 2024 at 17:22, Nick Couchman <vn...@apache.org> wrote: > On Thu, Aug 1, 2024 at 7:10 AM David Lomas <d...@pale-eds.co.uk.invalid> > wrote: > >> Hi Nick, >> >> I see from the dev group there's a lot of focus on the 1.6.0 release >> right now, but just wanted to post my progress here, and if you or anyone >> has time to confirm, that will at least save me the effort of continuing >> down a blind alley. >> >> > Hey, David, > Apologies for the lack of response - I've been traveling some lately, and > the day job was a bit busy there for a while, so I had not had time to sit > down and work through this. And, yes, we're pushing for the 1.6.0 release, > so a good deal of the time I've had to focus on Guacamole has gone into > trying to clean up things for that release :-). > > >> I've been able to create an auth extension which provides its own >> UserContext, and through the DecoratingDirectory class I can intercept the >> connect() method which actually comes from the load-balancing connection >> group feature of the jdbc extension. That function receives a >> GuacamoleClientInformation object and some tokens, but nothing about the >> remote end point. Calling super.connect() returns the GuacamoleTunnel which >> is established, but now we're no better off than using a listener for the >> TunnelConnect event; that class does not expose any information about the >> remote side. Interestingly, the tunnel is shown as an >> 'org.apache.guacamole.auth.jdbc.tunnel.ActiveConnectionRecord', but I've >> been unable to import any classes from the jdbc extension, and so can't use >> any of the methods on it. I'm not sure if that's as expected, or whether my >> environment isn't set up properly. I did try downloading the .jar for the >> jdbc extension, and although I can compile then, the code crashes at >> runtime. >> >> > A couple of things to consider: > * While ActiveConnectionRecord is a JDBC-specific class, it ultimately > implements the ConnectionRecord interface, which means you can call the > methods from that interface without the need to import the JDBC-specific > classes. > https://github.com/apache/guacamole-client/blob/main/guacamole-ext/src/main/java/org/apache/guacamole/net/auth/ConnectionRecord.java > * If you do want to import the JDBC classes, make sure that you have the > JDBC extension included as a dependency in your pom.xml file. > * You might see if doing something with the getActiveConnectionDirectory() > method in your UserContext implementation would help you. I think there are > a couple of options that might work - the existing ActiveConnection > directory might allow you to pull what you need, or, alternatively, you > could try overriding the getActiveConnectionDirectory() call and > implementing your own directory and/or ActiveConnection class that wraps > the underlying ones and performs the actions you're looking to do. > > I'm not _certain_ that any of these will actually get you where you want > to go, just throwing out ideas after looking at your requirements and the > code. You seem to be trying to do some things that I'm not sure were > completely thought of when the original code was written :-). > > >> I can get the tunnel UUID, and am wondering if I might then be able to >> use the REST API to get information about the remote end, since this is >> displayed in the admin UI? But that seems like a very round-about way of >> doing it. If the underlying GuacamoleTunnel had a method to expose the >> remote end info, that would be all we'd need... >> >> > Yes, you could do this, but if you can get the tunnel UUID, you can > probably get the tunnel without going around through the REST API - the > tunnel UUID itself isn't necessarily going to associate your active > connection with the underlying connection record. > > -Nick > >>
