Re: [jetty-dev] SslSelectChannelConnector Refactor Suggestion

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Chad,

This sounds like a good idea.... and now is the time to do any more
API changes before we go to a 7.0.0   (yes I know we did and RC0, but I
think that was a tad early/optimistic).

So a patch for this would be very welcome.  Can you also create a
bugzilla at eclipse to attach the patch to, as that should ask you
to ok the IP for inclusion.

   https://bugs.eclipse.org/bugs/

click   "Report a new bug" --> RT --> jetty

thanks in advance






Chad La Joie wrote:
> Hey all, I'd like to suggest a small refactor of the
> SslSelectChannelConnector class.
> 
> Background:
> I have an application that does not use standard PKIX validation during
> client-cert auth.  Instead there is a separate client descriptor file
> which contains, amongst other things, the certs which may be used by
> clients.  Therefore we have custom connectors for Tomcat and Jetty 6
> that use a "delegate to application" trust store (that it, the trust
> store says anything is good and it's up to the application to do the
> actual validation).
> 
> Now, I am NOT even beginning to suggest such functionality be integrated
> with any container.  It works for us because we have a controlled
> environment but I recognize it could cause all sorts of issues if
> deployed generally.  However, in trying to extend
> SslSelectChannelConnector in Jetty 7 the task is made more difficult
> because the reading in of the truststore (and keystore) are conflated
> with the creation of the SSLContext.  So my suggestion would be to break
> this apart.  Specifically I'd suggest the following:
> 
> - Change the [get|set][Keystore|Truststore] methods to be
> [get|set][Keystore|Truststore]Path and operate on Strings as they do now.
> 
> - Add methods get[Keystore|Truststore] which are responsible for doing
> something and returning a KeyStore object
> 
> - Use the new methods in createSSLContext
> 
> Doing this obviously helps me out but I think it also has some other
> minor benefits:
> -  The XML declaration of the connector may be a bit clearer since the
> property names 'KeystorePath' or 'TruststorePath' are a bit more
> self-documenting.
> - The createSSLContext shrinks down quite a bit (~50 lines of code are
> moved elsewhere)
> - A common "read in keystore" method could be used by both getKeystore
> and getTruststore and thus eliminate duplicate code.
> 
> If this sounds okay and you'd be interested in it I'll prepare a patch
> and submit it.  Just let me know, I'm certainly willing to do the bit of
> work required to make the change.
> 
> Thanks.
>