Document use of ldapurl with LDAP simple bind
Hi all,
Our documentation implies that the ldapurl setting in pg_hba is used
for search+bind mode only. It was pointed out to me recently that this
is not true, and if you're dealing with simple bind on a non-standard
scheme or port, then ldapurl makes the HBA easier to read:
... ldap ldapurl="ldaps://ldap.example.net:49151" ldapprefix="cn="
ldapsuffix=", dc=example, dc=net"
0001 tries to document this helpful behavior a little better, and 0002
pins it with a test. WDYT?
Thanks,
--Jacob
Attachments:
0001-docs-explain-how-to-use-ldapurl-with-simple-bind.patchapplication/octet-stream; name=0001-docs-explain-how-to-use-ldapurl-with-simple-bind.patchDownload+20-4
0002-ldap-test-ldapurl-with-simple-bind.patchapplication/octet-stream; name=0002-ldap-test-ldapurl-with-simple-bind.patchDownload+15-1
On 24.05.24 20:54, Jacob Champion wrote:
Our documentation implies that the ldapurl setting in pg_hba is used
for search+bind mode only. It was pointed out to me recently that this
is not true, and if you're dealing with simple bind on a non-standard
scheme or port, then ldapurl makes the HBA easier to read:... ldap ldapurl="ldaps://ldap.example.net:49151" ldapprefix="cn="
ldapsuffix=", dc=example, dc=net"0001 tries to document this helpful behavior a little better, and 0002
pins it with a test. WDYT?
Yes, this looks correct. Since ldapurl is really just a shorthand that
is expanded to various other parameters, it makes sense that it would
work for simple bind as well.
hba.c has this error message:
"cannot use ldapbasedn, ldapbinddn, ldapbindpasswd, ldapsearchattribute,
ldapsearchfilter, or ldapurl together with ldapprefix"
This appears to imply that specifying ldapurl is only applicable for
search+bind. Maybe that whole message should be simplified to something
like
"configuration mixes arguments for simple bind and search+bind"
(The old wording also ignores that the error might arise via "ldapsuffix".)
On Fri, Jun 28, 2024 at 12:11 AM Peter Eisentraut <peter@eisentraut.org> wrote:
This appears to imply that specifying ldapurl is only applicable for
search+bind. Maybe that whole message should be simplified to something
like"configuration mixes arguments for simple bind and search+bind"
(The old wording also ignores that the error might arise via "ldapsuffix".)
I kept the imperative "cannot" and tried to match the terminology with
our documentation at [1]https://www.postgresql.org/docs/17/auth-ldap.html:
cannot mix options for simple bind and search+bind modes
WDYT?
--Jacob
Attachments:
v2-0001-docs-explain-how-to-use-ldapurl-with-simple-bind.patchapplication/octet-stream; name=v2-0001-docs-explain-how-to-use-ldapurl-with-simple-bind.patchDownload+20-4
v2-0002-ldap-test-ldapurl-with-simple-bind.patchapplication/octet-stream; name=v2-0002-ldap-test-ldapurl-with-simple-bind.patchDownload+15-1
v2-0003-hba-improve-error-when-mixing-LDAP-bind-modes.patchapplication/octet-stream; name=v2-0003-hba-improve-error-when-mixing-LDAP-bind-modes.patchDownload+2-3
On 08.07.24 23:27, Jacob Champion wrote:
On Fri, Jun 28, 2024 at 12:11 AM Peter Eisentraut <peter@eisentraut.org> wrote:
This appears to imply that specifying ldapurl is only applicable for
search+bind. Maybe that whole message should be simplified to something
like"configuration mixes arguments for simple bind and search+bind"
(The old wording also ignores that the error might arise via "ldapsuffix".)
I kept the imperative "cannot" and tried to match the terminology with
our documentation at [1]:cannot mix options for simple bind and search+bind modes
Committed.
(I suppose this could be considered a bug fix, but I don't feel an
urgency to go backpatching this. Let me know if there are different
opinions.)
On Tue, Jul 23, 2024 at 1:37 AM Peter Eisentraut <peter@eisentraut.org> wrote:
Committed.
Thanks!
(I suppose this could be considered a bug fix, but I don't feel an
urgency to go backpatching this. Let me know if there are different
opinions.)
Certainly no urgency. The docs part of the patch also could be
backported alone, but I don't feel strongly either way.
--Jacob