On 05/03/18 22:18, Satyanarayana Narlapuram wrote:
> Please see the attached patch with the comments.
>
> Changes in the patch:
> A client-side PGREDIRECTLIMIT parameter has been introduced to control the maximum number of retries.
> BE_v3.1 sends a ProtocolNegotiation message. FE_v3.1 downgrades to v3.0 upon receipt of this message.
> FE falls back to v3.0 if 3.1 is not supported by the server.
>
>
> >> I hadn't really thought deeply about whether redirection should happen before or after authentication. For
themost part, before seems better, because it seems a bit silly to force people to authenticate just so that you can
tellthem to go someplace else. Also, that would lead to double authentication, which might for example result
inmultiple password prompts, which users might either dislike or find confusing.
>
> Yes, redirection before authentication would avoid multiple password prompts.
I think we should have this feature. I can see a redirect being useful
in some similar cases like HTTP redirects are useful, but a database
server is not a web server. There are no redirects in IMAP or most other
protocols, either.
This would also require modifying every client library to honor the
redirect.
How would the redirect behave with TLS certificate verification? If you
are redirected from "foo-server" to "bar-server", but the original
connection string was "host=foo-server sslmode=verify-full", would the
connection be allowed?
FWIW, if we were to do this, I think pg_hba.conf would be a fine place
for this. That's where you currently have configuration for what happens
when a client with certain host/username/database tries to connect. In
addition to "accept" or "reject", it seems logical to add "redirect" as
an outcome, instead of e.g. adding a whole new configuration file fore this.
But overall, IMHO we should mark this patch "rejected".
- Heikki
