Re: A solution to the SSL customizing problem

On Tuesday 12 October 2004 06:34, Oliver Jowett wrote:
> Ulrich Meis wrote:
> > On Tuesday 12 October 2004 04:57, Oliver Jowett wrote:
> >>So I suggest you look at solving the "how do I give the driver an
> >>appropriate SSLSocketFactory" problem first. Once that is solved, the
> >>particular configurable behaviour you want can be easily implemented.
> >
> > How about my suggestions with the abstract handler class?
> > I know it was a long post ;-)
>
> Namely:
> > In the Driver class you offer a method(make it empty if compiled without
> > SSL):
> >
> > setPGSSLHandler(PGSSLHandler handler) {
> >  pgsslhandler=handler;}
> >
> >
> > abstract class PGSSLHandler {
> >
> > public static final int STANDARD=0;
> > public static final int CUSTOMFACTORY=1;
> > public static final int CUSTOMSTORE=2;
> >
> > abstract public int getHandleType(int conid);
> > abstract public boolean getTrustAndSave(int conid);
> >
> > abstract public KeyStore getKeyStore(int conid);
> > abstract public SSLSocketFactory getSSLSocketFactory(int conid);
> >
> > }
>
> How do you arrange for setPGSSLHandler to be called if you are in a
> managed environment that does not know anything about the postgresql
> driver beyond the standard JDBC interfaces?

How about making it a static method?
You could only provide one handler per JVM but that will probably do in most
cases.

>
> The "conid" stuff looks really grotty. How do you coordinate the
> URL-level configuration with the PGSSLHandler implementation?

That coordination is up to the user.
He provides the conid in the URL and the driver just forwards it to the
handler method. I don't see a problem here.

> Why is anything but getSSLSocketFactory() needed? You can implement
> whatever keystore/truststore policy you want via a SSLSocketFactory.

I just thought it would be a nice feature because it spares people a lot of
work, nothing else ;-)

> The only new thing there is really the conid stuff, and I'd rather deal
> with classloader issues (specify the class by name, loaded by the
> driver) than have to deal with managing magic opaque unique
> configuration keys and a postgresql-specific interface.

The way I thought about it was that the connection just forwards the conid to
makeSSL. Then there is no need for the driver to manage it.

I thought - after reading previous posts about this - loading a user class
would not be an option because some environments might not allow the driver
to do so?

Uli