| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | Ajit Awekar <ajitpostgres(at)gmail(dot)com>, VASUKI M <vasukianand0119(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [OAuth2] Infrastructure for tracking token expiry time |
| Date: | 2026-02-18 16:30:24 |
| Message-ID: | 7F3C1A8B-F0FF-49BF-A53C-DC043BBB1FE7@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 18 Feb 2026, at 13:04, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>> 2. Terminating sessions with expired/revoked tokens before executing new
>> commands.
>
>> Token expiration is IMHO not a use case for a FATAL error, if we want to
>> terminate a connection we can do it in a more graceful way.
>
> There are different reasons for token expiration, one is a simple
> timeout where all we have to do is communicate to the client that we
> need a refresh (gracefully), and the other is where a token is
> immediately revoked because of a security incident, in which case
> immediate termination is a good practice.
I understand these cases and agree that there are different needs for messaging
to the user for these cases, but I still think that neither should overload
what FATAL error means. The mechanism used is however a secondary discussion,
first thing to get in place is a design for how to handle mid-connection
credential expiration.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-02-18 16:32:28 | Re: Lowering the default wal_blocksize to 4K |
| Previous Message | Daniel Gustafsson | 2026-02-18 16:21:10 | Re: Killing off anoncvs.postgresql.org |