Re: pg_authid.rolpassword format (was Re: [HACKERS] Passwordidentifiers, protocol aging and SCRAM protocol)
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_authid.rolpassword format (was Re: [HACKERS] Passwordidentifiers, protocol aging and SCRAM protocol) |
Дата | |
Msg-id | 9dc32483-b24a-5832-53e0-fb62838f1315@iki.fi обсуждение исходный текст |
Ответ на | Re: Password identifiers, protocol aging and SCRAM protocol (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: pg_authid.rolpassword format (was Re: [HACKERS] Passwordidentifiers, protocol aging and SCRAM protocol)
|
Список | pgsql-hackers |
On 12/14/2016 04:57 PM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote: >> On 12/14/16 5:15 AM, Michael Paquier wrote: >>> I would be tempted to suggest adding the verifier type as a new column >>> of pg_authid >> >> Yes please. > > This discussion seems to continue to come up and I don't entirely > understand why we keep trying to shove more things into pg_authid, or > worse, into rolpassword. I understand the relational beauty of having a separate column for the verifier type, but I don't think it would be practical. For starters, we'd still like to have a self-identifying string format like "scram-sha-256:<stuff>", so that you can conveniently pass the verifier as a string to CREATE USER. I think it'll be much better to stick to one format, than try to split the verifier into type and the string, when it enters the catalog table. > We should have an independent table for the verifiers, which has a > different column for the verifier type, and either starts off supporting > multiple verifiers per role or at least gives us the ability to add that > easily later. We should also move rolvaliduntil to that new table. I agree we'll probably need a new table for verifiers. Or turn rolpassword into an array or something. We discussed that before, however, and it didn't really go anywhere, so right now I'd like to get SCRAM in with minimal changes to the rest of the system. There is a lot of room for improvement once it's in. - Heikki
В списке pgsql-hackers по дате отправления: