PG14 and ldapfdw issue and latest Multicorn2 (v2.2.4)
mareban opened this issue · 3 comments
hello,
We still have issue with ldapfdw on PG14 using a where clause :-( !
Is it a bug, is ldapfdw still supported on an Active Directory ?
We are getting this error message from python : KeyError: 'attributes'
Thanks for your help.
PS : With PG10 and ldapfdw from Secfault it was working like a charm.
I'm hoping that Mathieu (highly skilled new commiter on this project) will fix this.
Hm... I don't have an LDAP system to test this against. @mareban is there an easy way to set one up and reproduce this issue? Can't guarantee I'd fix it, but I wouldn't know where to start in reproducing it right now. 🙂
If I had an LDAP system running to test this against (or if you do), what I would do is insert a line right before this...
multicorn2/python/multicorn/ldapfdw.py
Line 159 in 04c1667
And drop in:
log_to_postgres("entry = %r" % (entry,))
Considering the error KeyError: 'attributes'
, it seems likely that the attribute on line 159 is missing, so you'd have to peek at what it is returning instead and adapt -- either the search query is wrong or the API has changed, or, maybe the FDW needs to be resilient to attributes missing and skip entries?
I've been able to get the LDAP wrapper up-and-running against a test server using authentik (https://goauthentik.io/), and it works OK.
postgres=# CREATE FOREIGN TABLE ldapexample (
mail character varying,
cn character varying,
description character varying
) server ldap_srv options (
uri 'ldap://localhost:3389',
binddn 'cn=akadmin,ou=users,dc=ldap,dc=goauthentik,dc=io',
bindpwd '...some...password...',
objectClass 'inetOrgPerson',
path 'DC=ldap,DC=goauthentik,DC=io',
scope 'sub'
);
CREATE FOREIGN TABLE
postgres=# select * from ldapexample;
mail | cn | description
-------------------+---------------------------------------------+-------------
| ak-outpost-16f81e498b7f4e4d9ca8b41d5b24785d | []
| ak-outpost-2c91770182b54d3a9778afa2fd55c946 | []
email@example.com | akadmin | []
(3 rows)
The LDAP wrapper doesn't make any effort to validate the required table options which are documented in the code, but other than that, I can't see what the issue is here without more detailed reproduction steps. With no response from the submitter since May, I'm inclined to close this until more information is provided on the steps to reproduce.