Re: Periodic authorization expiration checks using GoAway message
| От | Jacob Champion |
|---|---|
| Тема | Re: Periodic authorization expiration checks using GoAway message |
| Дата | |
| Msg-id | CAOYmi+nG-+5gMu+GMHuSwRPAaqwstVnBfcXEqxyuC6m3jqjVhw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Periodic authorization expiration checks using GoAway message (Zsolt Parragi <zsolt.parragi@percona.com>) |
| Список | pgsql-hackers |
On Tue, Dec 16, 2025 at 12:05 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote: > a. The user presses the "logout everywhere" button > b. The users permissions change > c. The user is deactivated (e.g. employee termination) > d. A security check invalidates the user's session > > From these four, I think graceful logout/continuing the current query > is only an option for (a), maybe (b), for (c) and (d) we should log > out the user from everywhere as soon as possible. To me that seems like a matter of policy and not protocol. (As long as we come to some agreement on the semantics of what a client is and is not allowed to do before reauthenticating.) Said another way: it seems very useful to let a DBA choose between graceful reauthentication and hard connection loss for different situations. But I don't think those decisions should be assumed in the protocol design or hardcoded in our server. Even for case (d), a DBA might choose to bound clients via transaction_timeout for a particular application; since we've never had this feature before, I don't want to make proclamations about how people are going to want to deploy it. --Jacob
В списке pgsql-hackers по дате отправления: