No text in tree and search results

[href]

Hi there!

I was looking for an LDAP TUI tool and found yours. It looks nice, but for some reason I can't quite use it. The text in the tree of the LDAP Explorer and the Object Search seems to be missing:

Not sure what's going on.

I'm using Go 1.22 to compile it and run it on my macOS inside Tmux. It didn't help to run it outside of that though. It looks like the text is really not there (as opposed to being rendered in the same color as the background) - at least I can't select any text in the tree either.

Apart from that it seems to work. At least I'm not getting any errors.

Any idea what might be wrong?

[Macmod]

Hi there, I really have few ideas on this one without more details. I've seen the text come up empty during testing in cases where the user doesn't have required permissions to list specific objects.

Can you share some basic information on your target LDAP server and the commandline flags being used?

Also, have you tried running it in another OS? It might be OS-related too - I haven't tested godap in MacOS, so we might have all sorts of bugs there 😆

[href]

Sure, I ran the following commands. One from my macbook, one form the linux server itself. We use OpenLDAP / slapd.

godap <host> -u 'cn=admin,dc=example,dc=org' -p 'password' --ldaps --insecure --port 636 --format=false --emojis=false

In either instance the problem is the same. The thing is: I think the interaction with LDAP works perfectly fine. I can navigate through the tree in the first tab, and the information on the right is loaded and displayed. It looks correct too.

It's the tree that seems to not render the text. My uneducated guess is that on Windows there's some difference in how characters are rendered to the command-line which throws my terminal off. But I'm not very knowledgeable in this area.

What is difficult for me to assess if this works on a Linux Desktop, as I don't have one handy that can reach my LDAP server. However, I tried this in Terminal, iTerm2, and Alacritty. All with the same effect.

[Macmod]

OpenLDAP is most likely the issue, since godap was primarily written for Active Directory environments (I should make this clearer in the README in the near future). Although some features might work with OpenLDAP, I don't know much about it and haven't tested explicitly since I don't have an OpenLDAP lab. The names for the tree are taken either from the name attribute of the objects (when emojis are on) or distinguishedName (when emojis are off). Are these present in your environment?

If name is missing, maybe I can add a flag to use a custom attribute as the name, or to switch to a corresponding name attribute for OpenLDAP. Initially I thought about using cn which I think exists in OpenLDAP, but that's not a great option since in AD OUs don't have a cn. If a cn is present in OpenLDAP I could add a flag to switch from name to cn on-demand.

[href]

I think that might be it. Those entries are present on each of my entries:

• dn (Distingushed Name).
• cn (name, like you said).

I would certainly appreciate it if those values could be used if the Active Directory keys are missing.

[Macmod]

Can you build https://github.com/Macmod/godap/commit/868eee6bb815376d7579a0f6e1421c899241faa6 and check whether it works now? (This issue is too simple for me to branch, I'm just going for it in the main branch =P)

[Macmod]

Now that we're talking about OpenLDAP, it's likely that all other pages won't work properly, so I'd advise against trying to use them until I can think about some appropriate fallbacks. I'll open a separate issue for that.

The DACL page is very complex and AD-specific, but I don't see a reason why the other pages (object search & groups lookups) couldn't work with OpenLDAP, so I might work on a new release in the following weeks to address that. It's not exactly top priority, but if it could make some users happy I'll try to do it.

[href]

Hm that didn't help. I think it should, given that cn shows up int he attributes (though notably not in all - something that seems to contradict the output of ldapsearch):

Thanks also for the warning. I'm currently only running this against a lab environment anyway, so there's not much that it could break.

[Macmod]

I just set up a simple OpenLDAP instance and the fix seems to have worked when emojis are ON, but not when they are OFF because the dn didn't appear in the attributes set. Is that the case for you too?

[Macmod]

If so, this might be a fix - it worked in my environment: https://github.com/Macmod/godap/commit/0af3ba6ad1c2c1504f8fcc675b00072e8414c47b (+ https://github.com/Macmod/godap/commit/aa4828fd1293c3e39bc4ad69ec51051d5cd70ec2 to fix the name of the "root" entry)

[href]

It worked for me as well, thank you!