Re: A solution to the SSL customizing problem

Ulrich Meis wrote:
> On Tuesday 12 October 2004 06:34, Oliver Jowett wrote:
>
>>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.

That doesn't help..

The situation I am thinking of is when you are configuring a DataSource
for use in a managed environment, e.g. appserver. The appserver knows
nothing about the driver it is using beyond the standard JDBC interfaces
(and perhaps not even that, if it's using a JCA wrapper). This breaks as
soon as you have a magic method that needs to be called on the driver to
configure SSL properties. There is no way to teach the appserver how to
do this without hardwiring dependencies on the PG way of doing things..
which does not make for a very portable appserver!

>>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.

It's a maintenance nightmare. The configuration used by the handler
method has to somehow be kept in sync with the user configuration (the
URL). However, the handler method's configuration is not managed by the
same mechanisms that the user configuration is (namely "edit the JDBC URL").

>>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 ;-)

If you want to provide a default policy, you can do it as a separate
class. I don't see any reason for the extra methods in the driver-level
interface.

>>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?

The problem arises when the user code is in a disjoint classloader to
the driver's classloader. The driver cannot necessary load classes that
the user code can see. This is an issue if the handler is doing
something application-specific & is therefore part of the user code.

There is a related problem to do with passing around classnames in that
you cannot do multiple configurations just by instantiating new handlers
with different details, you either have to have lots of wrapper
implementations or something like the 'conid' scheme above along with
all the associated baggage.

...

Thinking about this a bit more, it seems to me that the use case that
hits the classloader issue (user code wanting feedback from the driver
via a nonstandard callback in a managed environment) is actually a hard
problem to solve anyway. It seems like if you need to do that you're
placing too high a burden on the appserver to magically know about the
behaviour of the nonstandard callback. The SSL configuration is really a
configuration property of the connection/connection pool, not something
that should be managed by user code in a managed environment. So maybe
we should forget about that case for the moment. Anyway..

I'd be OK with something like:

- a URL parameter that specifies name of a subclass of SSLSocketFactory
to use, and
- a method on the PG DataSource implementations that allows setting a
SSLSocketFactory *instance*. This instance is passed via a PG-private
API to the driver when creating connections from the DataSource. This
overrides use of the URL parameter.

i.e. you have:

if (SSLSocketFactory instance provided via DataSource)
use provided instance
else if (SSLSocketFactory classname provided via URL)
create new instance by name and use it
else
use default SSLSocketFactory

DataSource users configure the environment to instantiate a
SSLSocketFactory, configure it via reflection + javabean accessors, set
it via reflection on the DataSource. I think this is within the reach of
generic configuration mechanisms, they only need to know how to
manipulate the configuration objects via javabean accessors and don't
need to know anything specific to PG.

-O