Re: User functions for building SCRAM secrets
От | Dagfinn Ilmari Mannsåker |
---|---|
Тема | Re: User functions for building SCRAM secrets |
Дата | |
Msg-id | 874jvjk5su.fsf@wibble.ilmari.org обсуждение исходный текст |
Ответ на | User functions for building SCRAM secrets ("Jonathan S. Katz" <jkatz@postgresql.org>) |
Ответы |
Re: User functions for building SCRAM secrets
|
Список | pgsql-hackers |
"Jonathan S. Katz" <jkatz@postgresql.org> writes: > Attached is a (draft) patch that adds a function called > "scram_build_secret_sha256" that can take 3 arguments: This seems like a reasonable piece of functionality, I just have one comment on the implementation. > * password (text) - a plaintext password > * salt (text) - a base64 encoded salt […] > + /* > + * determine if this a valid base64 encoded string > + * TODO: look into refactoring the SCRAM decode code in libpq/auth-scram.c > + */ > + salt_str_dec_len = pg_b64_dec_len(strlen(salt_str_enc)); > + salt_str_dec = palloc(salt_str_dec_len); > + salt_str_dec_len = pg_b64_decode(salt_str_enc, strlen(salt_str_enc), > + salt_str_dec, salt_str_dec_len); > + if (salt_str_dec_len < 0) > + { > + ereport(ERROR, > + (errcode(ERRCODE_DATA_EXCEPTION), > + errmsg("invalid base64 encoded string"), > + errhint("Use the \"encode\" function to convert to valid base64 string."))); > + } Instead of going through all these machinations to base64-decode the salt and tell the user off if they encoded it wrong, why not accept the binary salt directly as a bytea? - ilmari
В списке pgsql-hackers по дате отправления: