Re: PATH: SSL flexibility and documentation - Mailing list pgsql-jdbc

Kris Jurka wrote:
> Documentation additions should ideally be to the docbook source in
> the doc subdirectory.

Alright.  I'll keep that in mind for the future.

As far as this patch, you've obviously thought about it and have the same
general idea as I do, so I'll let you take it from here.  I have no vested
interest in this functionality, and I only wrote the patch on the chance that
no one else had gotten around to it and it seemed pretty trivial.

As to your specific comments:

> I was initially thinking about a
> setSSLSocketFactory(Object) for the non-ssl case which would do
> nothing, but allow code that tried to use this ssl option to compile
> and run consistently.  That's not entirely consistent and perhaps
> setSSLSocketFactory should always take an Object parameter and
> conditionally cast it if using SSL.

That's exactly what I had in mind when I said it would be possible but ugly to
achieve both.  Something like:

@SSL@ private javax.net.ssl.SSLSocketFactory factory;

      public static void setSSLSocketFactory(Object factoryObj)
      {
@SSL@     this.factory = (javax.net.ssl.SSLSocketFactory) factoryObj;
      }

So you could still call setSSLSocketFactory even for a driver without SSL
compiled under JDK 1.1; but it wouldn't do anything.  Alternatively, perhaps
it should throw an exception.  I hate the idea of silently failing at
anything.

> One way around this would be to make the API something
> like setSSLSocketFactory(String factoryName, Object factory) and then
> have the url parameter be ?ssl=<factoryName>.

Sounds somewhat reasonable, but it does complicate the interface for the
common case.  If, instead, you had methods either to set the default factory
*or* use named factories, it wouldn't force anyone to figure out an
interaction between some String parameter and a piece of the connection URL.
I doubt most applications make connections to more than one backend anyway.

> This still doesn't
> solve the problem of trying to use something like this in a
> Datasource [...]

Didn't look into that, though I agree we should definitely worry about
DataSource support... especially with Sun floating around comments like "we
expect that DriverManager will be deprecated in a future JDBC release".

> Finally I'd like to take a closer look at the other ssl options that
> are available before I committed to an API that might not support
> them.  I know the server can optionally authenticate the client's
> cert and there are some other undocumented ssl things.

Sure.  There are options on SSLSocket as well that this doesn't provide access
to.  I can't think of a clean way to provide those options, except as yet more
separate parameters on top of this.  I can't imagine asking user code to hand
us back an SSLSocket instance.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation