On Thu, Aug 1, 2024 at 4:04 PM David Lomas <d...@pale-eds.co.uk.invalid> 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 >
