ldapjs / node-ldapjs

LDAP Client and Server API for node.js
http://ldapjs.org
MIT License
1.61k stars 448 forks source link

objectGUID attribute conversion changed as of ldapjs 3.0 #850

Closed TimFL closed 1 year ago

TimFL commented 1 year ago

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).

TimFL commented 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).

jsumners commented 1 year ago

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.

jsumners commented 1 year ago

I have updated the v3 release notes with this information.

genio commented 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).

how? Where are you using ;binary

seolhw commented 10 months ago

how? Where are you using ;binary

TimFL commented 9 months ago

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.

genio commented 9 months ago

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.