Re: A solution to the SSL customizing problem

On Tuesday 12 October 2004 10:23, Oliver Jowett wrote:

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

In an app server environment I would think that either the user obtains a
datasource object and provides handler and connection id as in

datasource.setjdbcurl("jdbc://server1/db1?handlerclass=mysslhandler&conid=1");con1=...
datasource.setjdbcurl("jdbc://server1/db1?handlerclass=mysslhandlerconid=2");con2=...

or uses a configuration file like

<datasource1>
<jdbcurl>.......conid=1</jdbcurl>

<datasource2>
<jdbcurl>......conid=2</jdbcurl>

where in this case the connection id identifies a database and not a
particular connection. Maybe it would better be called dbid.

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

If you can forward a class name from the URL to makeSSL, you can forward an id
as well and avoid the wrapper classes. Associated baggage stays the same.

>
> ...
>
> 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 agree that if you want to customize SSL settings and use multiple
configurations, you probably don't want to use the app server's connection
pool 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.

Sounds good to me.
I would suggest an additional URL parameter and method on PG DataSource for
the connection/database id.


Another completely different idea that I haven't tested and/or thought through
yet:

How about passing a JNDI name in the URL that users and/or app servers bind
their custom SSLSocketFactory to?
something like

context.bind("org/somewhere/sslfactory_companyA",new
mysslfactory("companyA"));
jdbcurl =
"jdbc:postgresql://companyA/workdb?sslsocketfactory=org/somewhere/sslfactory_companyA";
con=...

context.bind("org/somewhere/sslfactory_companyB",new mysslfactory("companyB");
jdbcurl =
"jdbc:postgresql://companyB/workdb?sslsocketfactory=org/somewhere/sslfactory_companyB";
con=...

Then you could forget about ids and the second class loading option.
JNDI is included since jdk1.3 and there's a jndi.jar for jdk1.2.


Uli