Re: A solution to the SSL customizing problem

On Tuesday 12 October 2004 23:12, Oliver Jowett wrote:
> Ulrich Meis wrote:
> > On Tuesday 12 October 2004 10:23, Oliver Jowett wrote:
> [...]

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

Alright, finally I got your point ;-)

> 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=t
>ruststore=foo,behaviour=bar

I totally agree.

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

How about passing

1. the URL without parameters so the factory knows which server&database it's
dealing with
2. a sslfactoryargs parameter as you described?

That way the factory can easily identify which certificate belongs to which
server.


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

Again, agreed.
I wanted to come around the problem that the user cannot provide his own
factory in a managed environment, but seeing that this functionality isn't
desired anyway, the problem vanishes.

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

My thoughts were upon simple-jndi from osjava for a stand alone application.

Uli