Re: [HACKERS] Client Connection redirection support for PostgreSQL

On Mon, Feb 12, 2018 at 1:56 PM, Satyanarayana Narlapuram
<Satyanarayana(dot)Narlapuram(at)microsoft(dot)com> wrote:
> I simplified the patch and for now just allowed one server. Please find the attached patches, and the commit message.

This patch --

-- doesn't include nearly sufficient documentation updates. For
example, the new message type is not documented in the list of message
types. The documentation of which messages are legal in which
contexts is not updated to mention this new message. The new
ConnStatusType is not documented (and is it really needed?). The
documentation for the new pg_hba.conf parameter does not explain how
to specify the alternate server to which you wish to connect.

-- includes no tests.

-- does include irrelevant whitespace differences.

-- doesn't include any provision for clients to fall back to 3.0 if
3.1 is not supported.

-- doesn't seem to have proper provisions for the server to handle
older clients. The code looks like just skips over hba.conf redirect
lines if the client is older, which seems like not what we want. The
proposed commit message claims we just go ahead and send redirects to
older clients that aren't expecting them, which is pretty much missing
the entire point of having minor protocol versions. I think the right
way to handle this case is to throw FATAL with the error text
suggesting the host/port to which the user should try connecting.

-- probably needs defenses against infinite redirect loops. Most
likely we should see how this is normally handled by HTTP clients and
do something similar here.

-- probably needs some way for clients to express unwillingness to
follow redirects. Possibly that could be combined with the previous
item by having a new connection parameter indicating the number of
redirects the client is willing to follow, with the default being,
say, 10 (browsers apparently have a limit of 10 or 20 for HTTP, but 20
seems overly generous for a database connection) and 0 disabling.

-- might need some defense against the redirected-to server getting
the same password as was sent to the original server. Is that a
security risk? Does HTTP have a rule about this?

-- might need some way for clients to discover whether they got
redirected and, if so, the server to which they were redirected. For
example, if I connect with psql, get redirected, and then type
\conninfo, do I get the information on the server to which I think I
connected, or the server to which I got redirected? Maybe we should
display both? If the connection gets retried, do we retry the
original server or the server to which we were redirected? I'd argue
for the former, but maybe other people think differently.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company