On Tue, 7 Jan 2003, Bruce Momjian wrote:
> Jon, I just documented the service/PGSERVICE capability in the CVS tree.
> It allows a pg_service.conf file that controls additional libpq
> connection options. In your app, you just do:
>
> connectdb("service=conn1")
>
> and "conn1" is looked up in pg_service.conf and it gets its other
> connection parameters from there. The code is already in 7.3. I just
> documented it, and changed auto-dbname setting to be active only when
> they don't specify a dbname. Also, I created a sample file called
> pg_service.conf.sample.
>
> This may provide a better way for you to control SSL rather than
> changing PGREQUIRE_SSL, which was also recently documented in the CVS
> tree.
I will take a look at the pg_service.conf file.
> I don't think overloading REQUIRE to mean something else is really the
> way to go. Looking at your options, we have:
>
> > > 0 - Refuse SSL
>
> Hard to imagine why someone would pick this one.
But this is the exact reason I started my patch -- I need a server that
can do SSL to allow *only* SSL connections to an off-site IP address, but
*only* non-SSL connections to an internal IP address on a private network.
Speed would suffer greatly if I were to allow SSL connections internally,
but security would suffer if I disabled all SSL connections.
> > > 1 - Negotiate, Prefer non-SSL
>
> This is the only new valid one. My question is why you would specify ssl
> on the host if you don't need ssl?
This is the one I don't see much need for, but I don't want to
second-guess people's needs if I can help it. Might as well put in all the
possibilities.
> > > 2 - Negotiate, Prefer SSL (default)
>
> Already the default for no requiressl.
>
> > > 3 - Require SSL
>
> Already requiressl.
>
> If the problem is that some apps need requiressl and others don't, I
> think the service file may be your cleanest option.
I hadn't heard of that before you checked in the docs patch yesterday, so
I'll check it out.
Thanks,
Jon
