I've raised an Improvement JIRA SSHD-121 and provided a first pass at a patch. I am not certain the patch represents the best or final answer, but I had to do the work anyway to be sure this proposal would actually meet my needs.
Thank you, Bill On Tue, Apr 19, 2011 at 9:37 AM, Bill Kuker <[email protected]> wrote: > Yes, I'd prefer to just use Factory<...> too. I had just been looking at > FileSystemFactory while I was thinking and didn't notice that it's create > method needed a String. > > > On Tue, Apr 19, 2011 at 9:04 AM, Guillaume Nodet <[email protected]> wrote: > >> Yeah, I think so. >> In all cases, I'd like NioSocketAcceptorFactory to implement >> Factory<IoAcceptor> to be consistent. >> I'm not really sure if there's a need to an explicit interface, as >> Factory looks sufficient for me, but why not. >> >> On Tue, Apr 19, 2011 at 14:59, Bill Kuker <[email protected]> >> wrote: >> > Would it make sense to add an NioSocketAcceptorFactory interface, and >> then >> > add several methods to ServerFactoryManager: >> > >> > getTcpipForwardNioSocketAcceptorFactory() >> > getX11ForwardNioSocketAcceptorFactory() >> > getSshServerNioSocketAcceptorFactory() [maybe] >> > >> > The last one could replace SshServer's createAcceptor() and >> > configure(IoAcceptor) methods. >> > Incidentally we are also patching TcpipForwardSupport to do the same >> > ReceiveBufferSize configuration that the SshServer does, but this could >> be >> > done in one default implementation of NioSocketAcceptorFactory. >> > >> > -Bill >> > >> > On Tue, Apr 19, 2011 at 3:16 AM, Guillaume Nodet <[email protected]> >> wrote: >> > >> >> You're absolutely right. >> >> The SshServer has a method that can be overriden, but not the >> >> TcpipForwardSupport nor the X11ForwardSupport. >> >> Using a factory for creating all NioSocketAcceptor would definitely be >> >> a good idea. There's already a Factory<T> class that can be used for >> >> that, so adding >> >> Factory<IoAcceptor> getIoAcceptorFactory(); >> >> to the ServerFactoryManager (and maybe a getIoConnectorFactory() on >> >> the ClientFactoryManager) is the way to go. >> >> Wanna raise a JIRA and eventually provide a patch? >> >> >> >> On Mon, Apr 18, 2011 at 15:45, Bill Kuker <[email protected]> >> wrote: >> >> > I had looked into that, but I could not figure out where to add it. >> The >> >> > entire process of accepting the connection and doing the necessary >> SSH >> >> > things to get the port forward working is handled entirely by Mina / >> >> SSHD; >> >> > there is no place for my application code to get into that process >> and >> >> mess >> >> > with the IoSession or SocketAcceptor. >> >> > >> >> > I had thought down the filter road before, and I believe I would need >> >> > something like an NioSocketAcceptorFactory (a new interface) that the >> >> > TcpipForwardSupport uses in initialize(), giving me a chance to wire >> in >> >> > whatever additional Filters I want? >> >> > >> >> > -Bill >> >> > >> >> > On Mon, Apr 18, 2011 at 9:36 AM, Ashish <[email protected]> >> wrote: >> >> > >> >> >> IMHO, using BlacklistFilter would be a better option >> >> >> >> >> >> Check out org.apache.mina.filter.firewall.BlacklistFilter >> >> >> >> >> >> thanks >> >> >> ashish >> >> >> >> >> >> On Mon, Apr 18, 2011 at 6:49 PM, Bill Kuker < >> [email protected]> >> >> >> wrote: >> >> >> > Hello. >> >> >> > >> >> >> > I am currently using the ForwardingFilter's canListen() & >> canConnect() >> >> >> > functions in my application to control which port forwards SSH >> clients >> >> >> are >> >> >> > allowed to create. I would like to also be able to filter incoming >> >> >> > connections to listening port forwards. For the moment I added a >> >> method >> >> >> to >> >> >> > the ForwardingFilter interface: >> >> >> > >> >> >> > boolean isAllowed(InetSocketAddress sourceAddress, >> >> InetSocketAddress >> >> >> > destinationAddress, ServerSession session); >> >> >> > >> >> >> > And check with it from TcpipForwardSupport's sessionCreated() >> >> function. >> >> >> > >> >> >> > >> >> >> > I think this is a useful capability for applications with embedded >> SSH >> >> >> > servers, and would like to submit a patch, rather than re-applying >> it >> >> to >> >> >> > each release, but I wanted to ask if there would be a better, more >> >> likely >> >> >> to >> >> >> > be accepted, design for it, and also ask if I have just missed a >> less >> >> >> > obvious way to accomplish this with the existing code. >> >> >> > >> >> >> > Thanks, >> >> >> > >> >> >> > Bill >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> thanks >> >> >> ashish >> >> >> >> >> >> Blog: http://www.ashishpaliwal.com/blog >> >> >> My Photo Galleries: http://www.pbase.com/ashishpaliwal >> >> >> >> >> > >> >> >> >> >> >> >> >> -- >> >> Cheers, >> >> Guillaume Nodet >> >> ------------------------ >> >> Blog: http://gnodet.blogspot.com/ >> >> ------------------------ >> >> Open Source SOA >> >> http://fusesource.com >> >> >> >> Connect at CamelOne May 24-26 >> >> The Open Source Integration Conference >> >> http://camelone.com/ >> >> >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> >> Connect at CamelOne May 24-26 >> The Open Source Integration Conference >> http://camelone.com/ >> > >
