Skip to content
This repository has been archived by the owner on May 14, 2024. It is now read-only.

objectGUID attribute conversion changed as of ldapjs 3.0 #850

Closed
TimFL opened this issue Mar 10, 2023 · 7 comments
Closed

objectGUID attribute conversion changed as of ldapjs 3.0 #850

TimFL opened this issue Mar 10, 2023 · 7 comments

Comments

@TimFL
Copy link

TimFL commented Mar 10, 2023

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 (#481 (comment)) 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
Copy link
Author

TimFL commented Mar 10, 2023

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

@TimFL TimFL closed this as completed Mar 10, 2023
@jsumners
Copy link
Member

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
Copy link
Member

I have updated the v3 release notes with this information.

@genio
Copy link

genio commented Sep 11, 2023

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
Copy link

seolhw commented Jan 12, 2024

how? Where are you using ;binary

@TimFL
Copy link
Author

TimFL commented Jan 17, 2024

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
Copy link

genio commented Jan 17, 2024

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.

@ldapjs ldapjs locked and limited conversation to collaborators Jan 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants