Re: A solution to the SSL customizing problem

Ulrich Meis wrote:
> 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=...

This is unlikely, the datasources are usually created and configured by
the appserver. That's one of the reasons for having a managed
environment in the first place..

> or uses a configuration file like
>
> <datasource1>
> <jdbcurl>.......conid=1</jdbcurl>
>
> <datasource2>
> <jdbcurl>......conid=2</jdbcurl>

A configuration file like this is the usual approach.

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

OK: so an administrator wants to add a new database that needs to use
SSL. They reconfigure the appserver with details of the driver & URL to
use, perhaps by editing a config file and restarting, perhaps by talking
to the running server via JMX, web interface, etc.  The URL includes a
new 'conid' value. To pick this value the administrator has to check all
the other connections by hand and find a new unique value. Fun!

Now, how does the administrator configure 'mysslhandler' to handle the
new 'conid' or 'dbid' they have just configured? Keep in mind that the
only mechanism they have access to for configuring things on the machine
may be whatever is provided by the appserver (JMX etc).. so "edit this
local file" or "change these system properties" are not useful answers.

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

See above :)

If you want to pass configuration information to the instantiated class
(and that is really what you're trying to do here, right?), a better way
seems to be to include all of that information directly in the URL
rather than adding more indirection. i.e. something like:

jdbc:postgresql://server:port/dbname?sslfactory=my.factory&sslfactoryargs=truststore=foo,behaviour=bar

Or even just provide the whole URL-derived Properties object to the
instantiated class and let it pick out whichever properties it wants.
Though I don't like passing all Properties as it makes the set of valid
properties for a connection unpredictable. Among other things this means
you can't correctly implement Driver.getPropertyInfo().

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

You have no guarantees that there is a JNDI provider available or that
it works as you expect from the driver's context or that you even have
permission to bind into it. So this seems like a really bad idea.

As a concrete example, if you try to do this in our appserver things are
going to blow up horribly -- there is a separate JNDI tree per
application, applications have a readonly view of their tree, and
non-application code such as JDBC drivers has no guarantees about which
tree (if any) is visible when they are executing.

> JNDI is included since jdk1.3 and there's a jndi.jar for jdk1.2.

The infrastructure is there, but the default providers leave a lot to be
desired. There's no purely in-memory provider, for example.

-O