LDAP Auth - Malformed UTF 8 #1617

Closed
opened 2026-02-05 01:26:14 +03:00 by OVERLORD · 6 comments
Owner

Originally created by @rocnetBinarian on GitHub (Mar 30, 2020).

Running bookstack v0.28.3, installed via the ubuntu script on a fresh LXC container. PHP 7.2.24-0ubuntu0.18.04.3, hosted on apache (http) with an nginx proxy (https) in front of it.

After submitting any password (correct or incorrect) for a valid user, an InvalidArgumentException is thrown: Malformed UTF-8 characters, possibly incorrectly encoded. Any password for an invalid user displays the normal "these credentials do not match our records"

Attempting to bind against Active Directory, not native LDAP.

My relevant config file, heavily edited but still similar:

AUTH_METHOD=ldap

LDAP_SERVER=192.168.50.5:389
LDAP_BASE_DN=ou=users,dc=example,dc=com
LDAP_DN=test@example.com
LDAP_PASS='test one test two'

LDAP_USER_FILTER=(&(sAMAccountName=${user}))
LDAP_VERSION=3

LDAP_ID_ATTRIBUTE=BIN;objectGUID
LDAP_EMAIL_ATTRIBUTE=mail
LDAP_DISPLAY_NAME_ATTRIBUTE=cn

LDAP_USER_TO_GROUPS=true
LDAP_GROUP_ATTRIBUTE="memberOf"
LDAP_REMOVE_FROM_GROUPS=false

LDAP_DUMP_USER_DETAILS=false

Per #1961 I have confirmed that LDAP_VERSION is 3, and that LDAP_ID_ATTRIBUTE is indeed BIN;objectGUID. No luck. One possible lead is that the AD server is rather old...perhaps too old for bookstack? Please advise, and thanks for the help!

Originally created by @rocnetBinarian on GitHub (Mar 30, 2020). Running bookstack v0.28.3, installed via the ubuntu script on a fresh LXC container. PHP 7.2.24-0ubuntu0.18.04.3, hosted on apache (http) with an nginx proxy (https) in front of it. After submitting any password (correct or incorrect) for a **valid user**, an InvalidArgumentException is thrown: `Malformed UTF-8 characters, possibly incorrectly encoded.` Any password for an **invalid user** displays the normal "these credentials do not match our records" Attempting to bind against Active Directory, not native LDAP. My relevant config file, heavily edited but still similar: ``` AUTH_METHOD=ldap LDAP_SERVER=192.168.50.5:389 LDAP_BASE_DN=ou=users,dc=example,dc=com LDAP_DN=test@example.com LDAP_PASS='test one test two' LDAP_USER_FILTER=(&(sAMAccountName=${user})) LDAP_VERSION=3 LDAP_ID_ATTRIBUTE=BIN;objectGUID LDAP_EMAIL_ATTRIBUTE=mail LDAP_DISPLAY_NAME_ATTRIBUTE=cn LDAP_USER_TO_GROUPS=true LDAP_GROUP_ATTRIBUTE="memberOf" LDAP_REMOVE_FROM_GROUPS=false LDAP_DUMP_USER_DETAILS=false ``` Per #1961 I have confirmed that LDAP_VERSION is 3, and that LDAP_ID_ATTRIBUTE is indeed BIN;objectGUID. No luck. One possible lead is that the AD server is rather old...perhaps too old for bookstack? Please advise, and thanks for the help!
Author
Owner

@ssddanbrown commented on GitHub (Apr 1, 2020):

Thanks for opening this on a new issue @rocnetBinarian.

Could you post the full Exception while LDAP_DUMP_USER_DETAILS=false is set? Should list a bunch of files and line numbers. Would be good to know exactly when this occurs, and hopefully that full exception detail should indicate what property this is thrown at.

Debugging details can be found here:
https://www.bookstackapp.com/docs/admin/debugging/

@ssddanbrown commented on GitHub (Apr 1, 2020): Thanks for opening this on a new issue @rocnetBinarian. Could you post the full Exception while `LDAP_DUMP_USER_DETAILS=false` is set? Should list a bunch of files and line numbers. Would be good to know exactly when this occurs, and hopefully that full exception detail should indicate what property this is thrown at. Debugging details can be found here: https://www.bookstackapp.com/docs/admin/debugging/
Author
Owner

@rocnetBinarian commented on GitHub (Apr 2, 2020):

Here ye be!

image

Thanks

@rocnetBinarian commented on GitHub (Apr 2, 2020): Here ye be! ![image](https://user-images.githubusercontent.com/59892178/78265256-333fe100-74d2-11ea-987c-4574912c68c6.png) Thanks
Author
Owner

@ssddanbrown commented on GitHub (Apr 4, 2020):

Thanks @rocnetBinarian, Is your LDAP_DUMP_USER_DETAILS definitely set to false or undefined when that error shows?

That error contains JsonDebugException which I would not set to see if that option was false.

@ssddanbrown commented on GitHub (Apr 4, 2020): Thanks @rocnetBinarian, Is your `LDAP_DUMP_USER_DETAILS` definitely set to false or undefined when that error shows? That error contains `JsonDebugException` which I would not set to see if that option was false.
Author
Owner

@rocnetBinarian commented on GitHub (Apr 6, 2020):

It is definitely set to false. I just tried commenting it out entirely as well, and same issue.

Edit: Just in case it was some weird caching issue, I set up a fresh new LXC container. Ran the ubuntu 18.04 install script. Before attempting to log in, modified the .env file to use my settings, and completely omitted the LDAP_DUMP_USER_DETAILS directive entirely. I then screwed around for 5 minutes trying to figure out why I was having problems (turns out I forgot to reload the nginx reverse proxy config), attempted to log in, and....it worked.

SO: I'm guessing there's some sort of caching thing that's causing it to still be broken. I'm going to attempt to break this new instance, and then see if I can unbreak it.

Update: Strange. I can break it, but I can also unbreak it. It's just that initial bookstack instance that won't play nice.

@ssddanbrown I can work with this; I'll create a new instance, make sure LDAP auth is working, and then import data from the current standalone instance. If you want to close the issue that's fine, but if you'd like to keep digging into it I'll keep the container around to provide you data as needed.

@rocnetBinarian commented on GitHub (Apr 6, 2020): It is definitely set to false. I just tried commenting it out entirely as well, and same issue. Edit: Just in case it was some weird caching issue, I set up a fresh new LXC container. Ran the ubuntu 18.04 install script. Before attempting to log in, modified the .env file to use my settings, and completely omitted the `LDAP_DUMP_USER_DETAILS` directive entirely. I then screwed around for 5 minutes trying to figure out why I was having problems (turns out I forgot to reload the nginx reverse proxy config), attempted to log in, and....it worked. SO: I'm guessing there's some sort of caching thing that's causing it to still be broken. I'm going to attempt to break this new instance, and then see if I can unbreak it. Update: Strange. I can break it, but I can also unbreak it. It's just that initial bookstack instance that won't play nice. @ssddanbrown I can work with this; I'll create a new instance, make sure LDAP auth is working, and then import data from the current standalone instance. If you want to close the issue that's fine, but if you'd like to keep digging into it I'll keep the container around to provide you data as needed.
Author
Owner

@ssddanbrown commented on GitHub (Apr 10, 2020):

@rocnetBinarian On the broken instance, do you have any files within the bootstrap/cache/?

If you have a bootstrap/cache/config.php file then your config may have been cached at the framework level. Can just delete that file if so.

@ssddanbrown commented on GitHub (Apr 10, 2020): @rocnetBinarian On the broken instance, do you have any files within the `bootstrap/cache/`? If you have a `bootstrap/cache/config.php` file then your config may have been cached at the framework level. Can just delete that file if so.
Author
Owner

@ssddanbrown commented on GitHub (Jan 11, 2021):

Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.

@ssddanbrown commented on GitHub (Jan 11, 2021): Since the last comment on this issue is relatively old I'm going to close this. If the issue remains and is something you still require to be fixed please open a new issue, referencing this one.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#1617