Re: dispchar for oauth_client_secret

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: dispchar for oauth_client_secret
Date: 2025-04-15 20:16:12
Message-ID: CAOYmi+kyt7Pw=5L6WyzGvnaU7EFdKi1Y3WG8Z8ia1mPfzj_qkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 15, 2025 at 12:14 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> I suspect this should use .dispchar="*" to encourage UIs to display
> oauth_client_secret like a password field. Thoughts?

Hmm, from a UI perspective I agree. (The builtin flow targets "public
clients", where secrets are discouraged and/or understood to be
not-really-secret, but there's no reason to assume that all flows used
by the application are public.)

From a proxy perspective, this would mess with FDW handling. By making
the dispchar '*', oauth_client_secret will be made into a user mapping
option rather than a server option. (Neither is very useful to
postgres_fdw anyway, because the builtin flow needs an end user to
interact with the provider.) But I'm not sure if we'll need to handle
compatibility in the future if we implement a proxy-friendly flow. Is
it okay to move options back and forth during a major version bump? I
assume it would present a problem for pg_upgrade?

Thanks!
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-04-15 20:20:00 Re: Add estimated hit ratio to Memoize in EXPLAIN to explain cost adjustment
Previous Message Tom Lane 2025-04-15 19:51:14 Re: not null constraints, again