Re: Add "host" to startup packet

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Add "host" to startup packet
Дата
Msg-id 982450.1680453184@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Add "host" to startup packet  (Greg Stark <stark@mit.edu>)
Ответы Re: Add "host" to startup packet  (Daniel Gustafsson <daniel@yesql.se>)
Список pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> My question is a bit different. How does this interact with TLS SNI.
> Can you just use the SNI name given in the TLS handshake? Should the
> server require them to match? Is there any value to having a separate
> source for this info? Is something similar available in GSSAPI
> authentication?

The idea that I was thinking about was to not hard-wire sending the host
string exactly, but instead to invent another connection parameter along
the line of "send_host = name-to-send".  This parallels the situation in
HTTP where the "Host" header doesn't necessarily have to match the actual
transport target.  I can think of a couple of benefits:

* Avoid breaking backward compatibility with old servers: if user doesn't
add this option then nothing extra is sent.

* Separating the send_host name would simplify testing scenarios.

Seems like it would depend a lot on your use-case whether you care about
the send_host name matching anything that's authenticated.  If you do,
there's a whole lot more infrastructure to build out around pg_hba.conf.
Right now that file is designed on the assumption that it describes
authentication rules for a single "host", but we'd need to generalize
it to describe rules for multiple host values.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: regression coverage gaps for gist and hash indexes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: regression coverage gaps for gist and hash indexes