Thanks Nick—getPrivileged() solved the problem in our override for UserContext. I still wasn't able to get that to work via the listener, which I thought might be a simpler solution, but never mind that for now.
What I can get to now is the ActiveConnection identifier, which appears to be just an int starting a 1 when the first user connects. Is there an exposed method that allows us to get the remote connection host name or IP address from there? I think we can do it via REST, and if that's the only way, then maybe we can just make the REST call using the java.net.HttpURLConnection classes we're also using to perform our external auth requests. But we'd also need to manage getting the access tokens, and it sounds a very round-about way of doing it. Many thanks, David On Thu, 1 Aug 2024 at 21:34, Nick Couchman <[email protected]> wrote: > On Thu, Aug 1, 2024 at 4:04 PM David Lomas <[email protected]> > wrote: > >> 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(); >> >> > This is a quick reply without looking through what you've said in a lot of > detail, but you can get a "privileged" version of the userContext object by > doing "userContext.getPrivileged()", which should allow you to do things as > a privileged "system" user that you wouldn't normally be able to do with > the userContext of the logged in user. Obviously you'd want to be careful > with this and what you're doing with it, and make sure you don't expose > anything to the user that would allow for unauthorized privilege > escalation, but it may get you where you need to go. > > >> 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? >> >> > No, I don't think what you're trying to do is outlandish at all :-). > > -Nick > >>
