[GH-ISSUE #797] [BUG] WebUI Case Sensitivity

kerem commented

2026-02-27 08:16:24 +03:00

Owner

Originally created by @inaneverb on GitHub (Jan 15, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/797

Describe the bug
Cannot login using 31-len username + 63-len password. But OK if used 5-len username + 11-len password.
I cannot login using these credentials by WebUI (17170 port), but Authelia can successfully login using these creds (at the startup check).

Perhaps, there's some cuts in WebUI? But even if it's so, there's no hint message, like (username too long, or password too long).

To Reproduce
Steps to reproduce the behavior:

Use username user1 and password password123 - OK. Everything is fine. Can login using WebUI, can login using Authelia.
Use username S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi and password LnAzLNVn16mVASPu1u5HlTe6SOcj4bQ2aHJkE4E1PB15Ntupz7BU24ujARvtvBO - Fail. Cannot login using WebUI, can login using Authelia.
Use username S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi and password password123 - Fail. Cannot login using WebUI, can login using Authelia.

Expected behavior
Any of:

Message about limits during lldap startup (something like "Fatal, username/password too long").
Successfully login using WebUI even when long username/password is used

Logs
Nothing special. According to my tests, providing correct or incorrect credentials leads to the same log message of lldap:

2024-01-15T12:40:39.243788611+00:00  DEBUG    HTTP request [ 2.77ms | 5.47% / 100.00% ] method: "POST" | uri: "/auth/opaque/login/start"
2024-01-15T12:40:39.243855252+00:00  DEBUG    ┝━ opaque_login_start [ 2.61ms | 2.39% / 94.53% ]
2024-01-15T12:40:39.243871172+00:00  DEBUG    │  ┕━ login_start [ 2.55ms | 77.98% / 92.14% ]
2024-01-15T12:40:39.243878932+00:00  DEBUG    │     ┕━ get_password_file_for_user [ 392µs | 14.16% ] user_id: UserId(CaseInsensitiveString("s46eaha4otdzpkljgmopz6jijvpl0xi"))
2024-01-15T12:40:39.247770526+00:00  DEBUG    ┕━ 🐛 [debug]:  | status_code: 200

Additional context
Maybe there's some limitations I don't know about? Are they mentioned somewhere?

Provided 31-len username and 63-len password are just randomly generated strings and obviously used only for local tests. So, I don't care exposing them here.

Originally created by @inaneverb on GitHub (Jan 15, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/797 **Describe the bug** Cannot login using 31-len username + 63-len password. But OK if used 5-len username + 11-len password. I cannot login using these credentials by WebUI (17170 port), but Authelia can successfully login using these creds (at the startup check). Perhaps, there's some cuts in WebUI? But even if it's so, there's no hint message, like (username too long, or password too long). **To Reproduce** Steps to reproduce the behavior: 1. Use username `user1` and password `password123` - OK. Everything is fine. Can login using WebUI, can login using Authelia. 2. Use username `S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi` and password `LnAzLNVn16mVASPu1u5HlTe6SOcj4bQ2aHJkE4E1PB15Ntupz7BU24ujARvtvBO` - Fail. **Cannot** login using WebUI, **can** login using Authelia. 3. Use username `S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi` and password `password123` - Fail. **Cannot** login using WebUI, **can** login using Authelia. **Expected behavior** Any of: - Message about limits during lldap startup (something like "Fatal, username/password too long"). - Successfully login using WebUI even when long username/password is used **Logs** Nothing special. According to my tests, providing correct or incorrect credentials leads to the same log message of `lldap`: ``` 2024-01-15T12:40:39.243788611+00:00 DEBUG HTTP request [ 2.77ms | 5.47% / 100.00% ] method: "POST" | uri: "/auth/opaque/login/start" 2024-01-15T12:40:39.243855252+00:00 DEBUG ┝━ opaque_login_start [ 2.61ms | 2.39% / 94.53% ] 2024-01-15T12:40:39.243871172+00:00 DEBUG │ ┕━ login_start [ 2.55ms | 77.98% / 92.14% ] 2024-01-15T12:40:39.243878932+00:00 DEBUG │ ┕━ get_password_file_for_user [ 392µs | 14.16% ] user_id: UserId(CaseInsensitiveString("s46eaha4otdzpkljgmopz6jijvpl0xi")) 2024-01-15T12:40:39.247770526+00:00 DEBUG ┕━ 🐛 [debug]: | status_code: 200 ``` **Additional context** Maybe there's some limitations I don't know about? Are they mentioned somewhere? --- _Provided 31-len username and 63-len password are just randomly generated strings and obviously used only for local tests. So, I don't care exposing them here._

kerem

2026-02-27 08:16:24 +03:00

closed this issue
added the
bug

frontend
labels

kerem commented

2026-02-27 08:16:24 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 15, 2024):

There are no meaningful restrictions on the user/password. The user ID should be <256 characters to fit in the DB, but that's not the issue here. The password is not actually sent to the server but a zero-knowledge proof is negotiated with the server to prove that you have the same password as when you registered. That proof uses the same code for the web login (where the client doesn't send the password) and for an LDAP login as with Authelia (where the client sends the password - the server acts as both parties to verify the proof).

Some things to test: Is it due to the password length or the username length? What if you try logging in with a long password and short username, or vice-versa?

As for the logs, logging in from the web UI takes 2 messages: You showed me the opaque_login_start, there should be an opaque_login_finish to match that, unless the password is wrong.

You say that logging in fails: what is the error? And at which step? Can you describe it more accurately?

@nitnelave commented on GitHub (Jan 15, 2024): There are no meaningful restrictions on the user/password. The user ID should be <256 characters to fit in the DB, but that's not the issue here. The password is not actually sent to the server but a zero-knowledge proof is negotiated with the server to prove that you have the same password as when you registered. That proof uses the same code for the web login (where the client doesn't send the password) and for an LDAP login as with Authelia (where the client sends the password - the server acts as both parties to verify the proof). Some things to test: Is it due to the password length or the username length? What if you try logging in with a long password and short username, or vice-versa? As for the logs, logging in from the web UI takes 2 messages: You showed me the `opaque_login_start`, there should be an `opaque_login_finish` to match that, unless the password is wrong. You say that logging in fails: what is the error? And at which step? Can you describe it more accurately?

kerem commented

2026-02-27 08:16:24 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

Thank you for your fast response.

Let me describe the setup more precisely.
There's 3 services: PostgreSQL (for LLDAP and Authelia), LLDAP and Authelia. All envs that are used for LLDAP and Authelia are linked to each other. So, generally speaking, Authelia's LLDAP vars derive their values from the LLDAP ones.

So, when I start the whole stack, both of LLDAP and Authelia runs fine. I mentioned it here, because Authelia has startup checks including check LLDAP conn with given credentials. And no matter what combination of described credentials here will I use, Authelia successfully passes that check. But, if I'd provide an explicitly incorrect password (not the same, that I give to LLDAP), it will fail during startup. This observations leads me to the following thought:

From the Authelia POV, any combination of login+pass I'm talking here about are correct and can be used to authenticate using LDAP protocol (3890 port).

Some things to test: Is it due to the password length or the username length? What if you try logging in with a long password and short username, or vice-versa?

In the first post I mentioned, that I also tried long username + short password and it leads to "Invalid username or password" error.

I tried the combination of short username + long password right now and it works correctly. I can login using either WebUI or Authelia.

So, I think the problem with the username's length.

As for the logs, logging in from the web UI takes 2 messages: You showed me the opaque_login_start, there should be an opaque_login_finish to match that, unless the password is wrong.

I tested again 2 cases:

Long username + short password
Long username + long password

Both of them has following artefacts:

"Invalid username or password" error in WebUI
No error in logs
Only opaque_login_start in logs and no presence of opaque_login_finish.

@inaneverb commented on GitHub (Jan 15, 2024): Thank you for your fast response. Let me describe the setup more precisely. There's 3 services: PostgreSQL (for LLDAP and Authelia), LLDAP and Authelia. All envs that are used for LLDAP and Authelia are linked to each other. So, generally speaking, Authelia's LLDAP vars derive their values from the LLDAP ones. So, when I start the whole stack, both of LLDAP and Authelia runs fine. I mentioned it here, because Authelia has startup checks including check LLDAP conn with given credentials. And no matter what combination of described credentials here will I use, Authelia successfully passes that check. But, if I'd provide an explicitly incorrect password (not the same, that I give to LLDAP), it will fail during startup. This observations leads me to the following thought: **From the Authelia POV, any combination of login+pass I'm talking here about are correct and can be used to authenticate using LDAP protocol (3890 port).** > Some things to test: Is it due to the password length or the username length? What if you try logging in with a long password and short username, or vice-versa? In the first post I mentioned, that I also tried long username + short password and it leads to "Invalid username or password" error. **I tried the combination of short username + long password right now and it works correctly. I can login using either WebUI or Authelia**. So, I think the problem with the username's length. > As for the logs, logging in from the web UI takes 2 messages: You showed me the opaque_login_start, there should be an opaque_login_finish to match that, unless the password is wrong. I tested again 2 cases: - Long username + short password - Long username + long password Both of them has following artefacts: - "Invalid username or password" error in WebUI - No error in logs - Only `opaque_login_start` in logs and no presence of `opaque_login_finish`.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@Masgalor commented on GitHub (Jan 15, 2024):

FYI
I can not reproduce this problem, all the given user/password combinations work for me.

LLDAP: 0.5.0
Browser: Firefox/Librewolf 121.0
Browser Addons: uBlock, LocalCDN

@Masgalor commented on GitHub (Jan 15, 2024): FYI I can not reproduce this problem, all the given user/password combinations work for me. LLDAP: [0.5.0](https://github.com/lldap/lldap/tree/v0.5.0) Browser: Firefox/Librewolf 121.0 Browser Addons: uBlock, LocalCDN

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

Ah, forgot to mention versions.

Docker image's version: lldap:2024-01-08-alpine
LLDAP version output: lldap 0.5.1-alpha
Browser: Chrome Version 120.0.6099.199 (Official Build) (arm64)

@Masgalor you cannot reproduce the problem using LLDAP's WebUI, right? Not the LDAP port.

@inaneverb commented on GitHub (Jan 15, 2024): Ah, forgot to mention versions. Docker image's version: `lldap:2024-01-08-alpine` LLDAP version output: `lldap 0.5.1-alpha` Browser: Chrome Version 120.0.6099.199 (Official Build) (arm64) @Masgalor you cannot reproduce the problem using LLDAP's WebUI, right? Not the LDAP port.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@Masgalor commented on GitHub (Jan 15, 2024):

Right, I'm talking about the WebUI.

@Masgalor commented on GitHub (Jan 15, 2024): Right, I'm talking about the WebUI.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 15, 2024):

And there are no JS errors in the dev console?

@nitnelave commented on GitHub (Jan 15, 2024): And there are no JS errors in the dev console?

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

@nitnelave yes, I have JS error in dev console. Sorry for forgetting to check it and provide it alongside with the report.

Invalid username or password: Protocol error: `This error results from an error during password verification`

It refers to lldap_app.js:597.

@inaneverb commented on GitHub (Jan 15, 2024): @nitnelave yes, I have JS error in dev console. Sorry for forgetting to check it and provide it alongside with the report. ``` Invalid username or password: Protocol error: `This error results from an error during password verification` ``` It refers to `lldap_app.js:597`.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@Masgalor commented on GitHub (Jan 15, 2024):

Do you have a reverse-proxy or a waf in front of lldap?
Maybe something is limiting your request size or changing your request in another way.

@Masgalor commented on GitHub (Jan 15, 2024): Do you have a reverse-proxy or a waf in front of lldap? Maybe something is limiting your request size or changing your request in another way.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

Do you have a reverse-proxy or a waf in front of lldap?
Maybe something is limiting your request size or changing your request in another way.

For all these testings - nope. I use SSH tun to the remote machine directly to the LLDAP WebUI port. So, it's only SSH tun + Docker routes.
SSH tun is opened by ssh -L 17170:<lldap_ip>:17170 <server_ip> -Nv

@inaneverb commented on GitHub (Jan 15, 2024): > Do you have a reverse-proxy or a waf in front of lldap? Maybe something is limiting your request size or changing your request in another way. For all these testings - nope. I use SSH tun to the remote machine directly to the LLDAP WebUI port. So, it's only SSH tun + Docker routes. SSH tun is opened by `ssh -L 17170:<lldap_ip>:17170 <server_ip> -Nv`

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 15, 2024):

Could we get a screenshot of the network requests from the browser when trying to log in?
The JS error is expected (it means it couldn't verify the password, likely because the password was wrong).

@nitnelave commented on GitHub (Jan 15, 2024): Could we get a screenshot of the network requests from the browser when trying to log in? The JS error is expected (it means it couldn't verify the password, likely because the password was wrong).

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

Could we get a screenshot of the network requests from the browser when trying to log in?
The JS error is expected (it means it couldn't verify the password, likely because the password was wrong).

Sure. I attached the screenshot. Also, looks like the main request is start, because there's no other one. So, here's the data of it:

JSON request

{
  "username": "S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi",
  "login_start_request": "xlIiZqCbLsbIN2o9++czjj/b2B1PvS0jWyEgj+9IhzjHtabC5+Ii5AxpMlRv8d7k0TQ6r2+troAoZWkbSi/mDcQ/h2qdIO2tMky6OgmdI+nliHSJxwVBxN3AQpmTn9US"
}

JSON response

{
    "server_data": "/8DATnRwTnY21tUGdO/PcH0DBaeZ0oc0QAplrl9rm5aAQoVP2e87oYwlrDAmNle3k1zrwXU0pnmK4aNR+3yQu3POKCjLrFiZ618EFJcR9I6mHCHta2kz1pEISjLKUAJSTOC0CpesDlBJwAKIpSbcXvf9LnEDutqAL9K7qAkgE8sDMjXntVN6Pyn8VqX+K3i6+qqJaCB6H2F4velE/l4lp8bgwMUSR2gbYuhXVjqQvk0ESriKnLVo9HNjEfJMMCK2f+A/TxMOrej0acxosw32aGOQhqbqUj85F+OHjfTgBv+ux2wQgNHom9fALx6QHULAXMI03f9cVI8SIyaGWuBGCIKMUOjUo+lM1Zu6BHE8zB4pJSYVMDlC",
    "credential_response": "AipMrM/IiBKHqZIFiBUMeyFfRoHszs8VfV0BbN91Y2qwy5dXjSpoMdcoRR17SGp7urIP+SWM6ZIh3ZKeamh9LWEprGiDm4DdmxASAgfAk6s94J1Y8JaSdO+GeJVxS39wXxiVdXmoK9Q42hipZKJ+KgE3mb5e7I43rclN+wzAaJSxBHPyKthEKa8MmiQp/FZ05IUYlxkJDrnie7upfOVRPkbRgrZgBKDIyfUHJnr9mD4qu/RSSlfSDGo8WBKu/cAfgB+uDz15oUkz8uJYEAw8I2xZSDuQ8v2nVTU75dtdMKqK+1UEzIdyJ9Z2dnGA8jN1Zmm7T3DYVr/ZopIWQeK6MJejVEUrHiKKmZz1mi1/rBMg0W4wC8+Kgai9WdhaIVsr9EX0voFF0Tuf+ypwxvt1DiKJ6+cdV7bwqq8X3G0ZMcE="
}

Moreover, if it may help you to investigate I may provide all ENVs using which LLDAP is started.

ENV secrets

LLDAP_JWT_SECRET="kL6raWXhw2n57PaqnPDvUxxAFhd6Oep4atrmhlFQcRS0P1PF7hzDjG51Xj1S47x"
LLDAP_KEY_SEED="ZXchTCmdmoRQNn4YbMVTkZ4kTSOyd1n6mcOFgZ7VXrTellYmQ1Fy7id7sIrPtY1"
LLDAP_LDAP_BASE_DN="dc=S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi,dc=com"
LLDAP_LDAP_USER_DN="S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi"
LLDAP_LDAP_USER_EMAIL="inaneverb@example.com"
LLDAP_LDAP_USER_PASS="password123"

Screenshot

@inaneverb commented on GitHub (Jan 15, 2024): > Could we get a screenshot of the network requests from the browser when trying to log in? The JS error is expected (it means it couldn't verify the password, likely because the password was wrong). Sure. I attached the screenshot. Also, looks like the main request is `start`, because there's no other one. So, here's the data of it: <details><summary>JSON request</summary> <pre> { "username": "S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi", "login_start_request": "xlIiZqCbLsbIN2o9++czjj/b2B1PvS0jWyEgj+9IhzjHtabC5+Ii5AxpMlRv8d7k0TQ6r2+troAoZWkbSi/mDcQ/h2qdIO2tMky6OgmdI+nliHSJxwVBxN3AQpmTn9US" } </pre> </details> <details><summary>JSON response</summary> <pre> { "server_data": "/8DATnRwTnY21tUGdO/PcH0DBaeZ0oc0QAplrl9rm5aAQoVP2e87oYwlrDAmNle3k1zrwXU0pnmK4aNR+3yQu3POKCjLrFiZ618EFJcR9I6mHCHta2kz1pEISjLKUAJSTOC0CpesDlBJwAKIpSbcXvf9LnEDutqAL9K7qAkgE8sDMjXntVN6Pyn8VqX+K3i6+qqJaCB6H2F4velE/l4lp8bgwMUSR2gbYuhXVjqQvk0ESriKnLVo9HNjEfJMMCK2f+A/TxMOrej0acxosw32aGOQhqbqUj85F+OHjfTgBv+ux2wQgNHom9fALx6QHULAXMI03f9cVI8SIyaGWuBGCIKMUOjUo+lM1Zu6BHE8zB4pJSYVMDlC", "credential_response": "AipMrM/IiBKHqZIFiBUMeyFfRoHszs8VfV0BbN91Y2qwy5dXjSpoMdcoRR17SGp7urIP+SWM6ZIh3ZKeamh9LWEprGiDm4DdmxASAgfAk6s94J1Y8JaSdO+GeJVxS39wXxiVdXmoK9Q42hipZKJ+KgE3mb5e7I43rclN+wzAaJSxBHPyKthEKa8MmiQp/FZ05IUYlxkJDrnie7upfOVRPkbRgrZgBKDIyfUHJnr9mD4qu/RSSlfSDGo8WBKu/cAfgB+uDz15oUkz8uJYEAw8I2xZSDuQ8v2nVTU75dtdMKqK+1UEzIdyJ9Z2dnGA8jN1Zmm7T3DYVr/ZopIWQeK6MJejVEUrHiKKmZz1mi1/rBMg0W4wC8+Kgai9WdhaIVsr9EX0voFF0Tuf+ypwxvt1DiKJ6+cdV7bwqq8X3G0ZMcE=" } </pre> </details> Moreover, if it may help you to investigate I may provide all ENVs using which LLDAP is started. <details><summary>ENV secrets</summary> <pre> LLDAP_JWT_SECRET="kL6raWXhw2n57PaqnPDvUxxAFhd6Oep4atrmhlFQcRS0P1PF7hzDjG51Xj1S47x" LLDAP_KEY_SEED="ZXchTCmdmoRQNn4YbMVTkZ4kTSOyd1n6mcOFgZ7VXrTellYmQ1Fy7id7sIrPtY1" LLDAP_LDAP_BASE_DN="dc=S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi,dc=com" LLDAP_LDAP_USER_DN="S46EAHa4OTDzPkLjGmOPZ6jIjVpL0Xi" LLDAP_LDAP_USER_EMAIL="inaneverb@example.com" LLDAP_LDAP_USER_PASS="password123" </pre> </details> <details><summary>Screenshot</summary> <img width="1512" alt="Screenshot 2024-01-15 at 4 11 42 PM" src="https://github.com/lldap/lldap/assets/16417743/1976ea59-e618-403f-9cc7-42af594ed9e0"> </details>

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@martadinata666 commented on GitHub (Jan 15, 2024):

I think this is about case sensitivity. 🤔 Rather than character size.

@martadinata666 commented on GitHub (Jan 15, 2024): I think this is about case sensitivity. 🤔 Rather than character size.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 15, 2024):

I think this is about case sensitivity. 🤔 Rather than character size.

@martadinata666 Seems like you're right. I just tested User1/password123 and user1/password123. First one has been failed and second one successfully logged in.

@inaneverb commented on GitHub (Jan 15, 2024): > I think this is about case sensitivity. 🤔 Rather than character size. @martadinata666 Seems like you're right. I just tested `User1/password123` and `user1/password123`. First one has been failed and second one successfully logged in.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 15, 2024):

erf, yeah I see it. That should be an easy fix.

@nitnelave commented on GitHub (Jan 15, 2024): erf, yeah I see it. That should be an easy fix.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 15, 2024):

@inaneverb can you confirm that it's fixed in latest?

@nitnelave commented on GitHub (Jan 15, 2024): @inaneverb can you confirm that it's fixed in latest?

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@inaneverb commented on GitHub (Jan 16, 2024):

@nitnelave yes, I can confirm that the bug is fixed. Tested in the :latest-alpine docker image.

Not quite sure that it's expected behaviour, 'cause when I'm logged in I see that my username is lowercase forced despite the case it has been provided originally.
I understand that likely it's the best option to provide backward compatibility and case sensitivity for entities like username, logins, etc is still discussible topic. However, maybe it's better to display username with the same case it has been provided by the user during its creation and use case-insensitive variant of it during some checks and lookups.

Anyway. It works and you got my big thanks for the blazing fast delivery of that fix.
Thank you.

@inaneverb commented on GitHub (Jan 16, 2024): @nitnelave yes, I can confirm that the bug is fixed. Tested in the `:latest-alpine` docker image. Not quite sure that it's expected behaviour, 'cause when I'm logged in I see that my username is lowercase forced despite the case it has been provided originally. I understand that likely it's the best option to provide backward compatibility and case sensitivity for entities like username, logins, etc is still discussible topic. However, maybe it's better to display username with the same case it has been provided by the user during its creation and use case-insensitive variant of it during some checks and lookups. Anyway. It works and you got my big thanks for the blazing fast delivery of that fix. Thank you.

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 16, 2024):

The username is stored lowercase in the DB (as are most case-insensitive strings apart from email and group names), so it gets displayed as lowercase.

I try to strive for utility first, so a "nicer-looking" feature that would add complexity doesn't pass the bar :)

@nitnelave commented on GitHub (Jan 16, 2024): The username is stored lowercase in the DB (as are most case-insensitive strings apart from email and group names), so it gets displayed as lowercase. I try to strive for utility first, so a "nicer-looking" feature that would add complexity doesn't pass the bar :)

kerem commented

2026-02-27 08:16:25 +03:00

Author

Owner

@nitnelave commented on GitHub (Jan 16, 2024):

And note that thanks to your report, I also fixed the lldap_set_password binary that had the same case-sensitivity issues!

@nitnelave commented on GitHub (Jan 16, 2024): And note that thanks to your report, I also fixed the `lldap_set_password` binary that had the same case-sensitivity issues!

Rows
Columns

[GH-ISSUE #797] [BUG] WebUI Case Sensitivity #287