Re: [PoC] Federated Authn/z with OAUTHBEARER - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: [PoC] Federated Authn/z with OAUTHBEARER
Date
Msg-id aAOREVWMFTuWvJ1l@msg.df7cb.de
Whole thread Raw
In response to Re: [PoC] Federated Authn/z with OAUTHBEARER  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
Re: Jacob Champion
> > libpq_append_conn_error(conn, "no custom OAuth flows are available,
> > and libpq-oauth could not be loaded library could not be loaded. Try
> > installing the libpq-oauth package from the same source that you
> > installed libpq from");
> 
> Thanks! I think that's a little too prescriptive for packagers,
> personally, but I agree that the current message isn't correct
> anymore. I've gone with "no custom OAuth flows are available, and the
> builtin flow is not installed".

This whole oauth business is highly confusing if you aren't a web
security expert. It's a pretty long way from "the builtin flow is not
installed" to "if you want this to work, you need to install an extra
library/package on the client", so I don't think this message is
helpful.

The originally suggested message was pretty good in that regard. The
distinction about custom flows could probably be dropped.

How about this:

  No libpq OAuth flows are available. (Try installing the libpq-oauth package.)

People who have custom flows will likely know that they have to do
anyway.

Devrim: Does that match the package name you'd use?

> (I suppose packagers could patch in a
> platform-specific message if they really wanted?)

We could, but I'd prefer if we didn't have to. :*)

Christoph



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: disabled SSL log_like tests
Next
From: Sami Imseih
Date:
Subject: Re: [BUG] temporary file usage report with extended protocol and unnamed portals