I'm still experiencing this. Was there a resolution?

seems to be expected behavior for fmt.Sscanln

Hi @jamesalbert
I'm not familiar with LDAP in depth, what does that mean? Should I reopen the issue?

IT sysadmin here:
LDAP, or in my case Microsoft Active Directory, which also uses LDAP, in fact supports spaces in the names of organisation units (OUs). This effects almost any type of bject in LDAP, except domainnames itself.
So given a distinguished name (DN) of "CN=foobar,OU=foo bar,DC=foo,DC=bar" is actually different from "CN=foo bar,OU=foobar,DC=foo,DC=bar"
In fact, in Microsoft Ative Directory there is a builtin OU named "Domain Administrators", which you SHOULD NOT edit in any way.
When i try to set "ldap_searchdn" : "OU=Domain Administrators,DC=foo,DC=bar" the function breaks the line, this is a bug from the LDAP point of view.

This behaviour still applies.
Following the suggestion from @jamesalbert , I found this post:
https://stackoverflow.com/a/43843848
So, when the function finds my ldap path that contains a space in it , the sscanln stops reading the input at the space.

This results in an incorrect input for the remainder of the code referenced by @jamesalbert in his previous reply.

Also , as pointed out by @JgdKdoFhr , Active Directory uses spaces in built on OUs so, no workarounds there.

Reading through the code I realised that if I use a config file , the part os the code that breaks because of the sscanln behaviour around spaces is skipped .

So, around that line of inquiry, I got it working by creating the config file and creating a bind volume in my docker compose file.

I think that the bufferio.scanner path could solve this issue .

I will fork the repo and try the bufferio.scanner path .