Closed TimFL closed 1 year ago
I solved it:
Instead of requesting the attribute objectGUID
I am now requesting the attribute objectGUID;binary
, which returns the values as base64 which I can then correctly parse into a Buffer and translate into the GUID using the methods mentioned above (the crazyx13th and my old functions, they all work).
It is possible there was some data inspection done in the prior release that detected a binary attribute and handled it in some way. I don't recall seeing that, but it could very well be there. Regardless, with v3 we are being much more strict about following the RFCs. If a binary attribute is to be requested, it should be requested with the ;binary
option as you have shown.
Regarding .raw
vs .pojo
: you should investigate the objects for the fields and such they support. In particular:
The .attributes
will return an array of https://github.com/ldapjs/attribute/blob/d1cba4723fb6953a932a71b53a8d842eeab564c7/index.js objects. Such objects have a .values
property that will render binary attributes as encoded strings.
I have updated the v3 release notes with this information.
I solved it:
Instead of requesting the attribute
objectGUID
I am now requesting the attributeobjectGUID;binary
, which returns the values as base64 which I can then correctly parse into a Buffer and translate into the GUID using the methods mentioned above (the crazyx13th and my old functions, they all work).
how? Where are you using ;binary
how? Where are you using ;binary
how? Where are you using ;binary
In the code where you specify which attributes you want your LDAP method to return, instead of saying objectGUID
you put objectGUID;binary
as attribute name.
Going through User objects and then going through the User's Attributes allows access with attribute.buffers[0]
.
The interface is really not documented well and is all over the place in multiple repos (some of which have zero docs). The spaghetti effect is real. The pojo
object (terrible name change -ugh- wasn't documented well again) screws up the ability to get the buffers correctly.
Overall, I'm not a fan of this rewrite, but I'm at least finally able to get everything I need even if it's in a round-about way.
There seems to have changed something with returned values in ldapjs 3.x. I'm trying to convert the returned objectGUID value to a readable uuid string. All of my tried functions no longer return the correct objectGUID string, it's always off by a few characters / digits. Example:
crazyx13th function (https://github.com/ldapjs/node-ldapjs/issues/481#issuecomment-884041032) returns this: fd15fd05-5879-4866-fdfd-6afd1f61526f but it should actually be this: f715f905-5879-4866-8cd8-6ae81f61526f
Any help would be appreciated as this bricks a lot of functionality in a new project using ldapjs 3.x
Strangely, the counterpart function I used to convert a string uuid into a Buffer (for e.g. ldap search queries that filter based on objectGUID) continue to work as expected. It's only the objectGUID to UUID method (e.g. crazyx13th variant) that returns slightly off values.
This could potentially be solved by getting the raw buffer object, although I can't seem to use entry.raw anymore (only entry.pojo).