starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #516] Unable to access user if white spaces are in username. #189

New issue

Closed

opened 2026-02-27 08:15:46 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 08:15:46 +03:00

Owner

Originally created by @Normanras on GitHub (Mar 31, 2023).
Original GitHub issue: https://github.com/lldap/lldap/issues/516

The CreateUserModel doesn't explicitly require the use or non-use of white spaces in a username. I believe this function is for creating the user.

However, after the user is created, if you try to click on the user to change other values, I get this error:
Error: Error getting user details: Errors: [user:2:3: Entity not found: 'test%20user%20with%20spaces']

I've attached screenshots of the three steps to recreate:

Create a user with whitespaces in the username field.
Save that user & verify they are in the users list on the dashboard.
Click that user's username to access the user's settings.

I'm happy to open a PR for this fix, but I think @nitnelave and any other core devs need to make a decision on whitespaces in username. This may be related to issue #239 .

The possible options I'm thinking of:

validate or assert that the String.contains(char::is_whitespace)); and throw an error
Automatically replace() & remove the whitespaces
Allow whitespaces & update the db to allow them.
Something else I'm missing?

My assumption with a username is that whitespaces should not be allowed as I've yet to see a unique username with a whitespace.

Screenshots. First, add the user:

Second, click save and verify the user is on the dashboard:

Third, click on the user:

Originally created by @Normanras on GitHub (Mar 31, 2023). Original GitHub issue: https://github.com/lldap/lldap/issues/516 The `CreateUserModel` doesn't explicitly require the use or non-use of white spaces in a username. I believe [this function](https://github.com/lldap/lldap/blob/main/app/src/components/create_user.rs#L32) is for creating the user. However, after the user is created, if you try to click on the user to change other values, I get this error: `Error: Error getting user details: Errors: [user:2:3: Entity not found: 'test%20user%20with%20spaces']` I've attached screenshots of the three steps to recreate: 1. Create a user with whitespaces in the `username` field. 2. Save that user & verify they are in the users list on the dashboard. 3. Click that user's username to access the user's settings. I'm happy to open a PR for this fix, but I think @nitnelave and any other core devs need to make a decision on whitespaces in username. This _may_ be related to issue #239 . The possible options I'm thinking of: 1. `validate` or `assert` that the `String.contains(char::is_whitespace));` and throw an error 2. Automatically `replace()` & remove the whitespaces 3. Allow whitespaces & update the db to allow them. 4. Something else I'm missing? My assumption with a username is that whitespaces should not be allowed as I've yet to see a unique username with a whitespace. Screenshots. First, add the user: ![Screenshot 2023-03-31 at 1 22 16 PM](https://user-images.githubusercontent.com/44226464/229191540-bc0908b4-a95c-4847-bb5f-d1279285f95a.png) Second, click save and verify the user is on the dashboard: ![Screenshot 2023-03-31 at 1 22 23 PM](https://user-images.githubusercontent.com/44226464/229191627-235b93c4-199b-43ac-b002-169869a1ea74.png) Third, click on the user: ![Screenshot 2023-03-31 at 1 22 32 PM](https://user-images.githubusercontent.com/44226464/229191702-00f2af32-8b70-472d-a307-33f632ed1d07.png)

kerem

2026-02-27 08:15:46 +03:00

closed this issue
added the
bug

good first issue

frontend
labels

kerem commented

2026-02-27 08:15:46 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 31, 2023):

Yep, definitely needs more restrictions on the username.

@nitnelave commented on GitHub (Mar 31, 2023): Yep, definitely needs more restrictions on the username.

kerem commented

2026-02-27 08:15:46 +03:00

Author

Owner

@pixelrazor commented on GitHub (Mar 31, 2023):

I agree re: restrictions. As far as the actual bug here, i think the frontend is doing some escaping of the spaces which is causing it to not work as intended. I'd imagine spaces SHOULD work just fine, but i wouldn't be surprised if thre's actual issues beyond the escaping of the chars in the frontend

@pixelrazor commented on GitHub (Mar 31, 2023): I agree re: restrictions. As far as the actual bug here, i think the frontend is doing some escaping of the spaces which is causing it to not work as intended. I'd imagine spaces SHOULD work just fine, but i wouldn't be surprised if thre's actual issues beyond the escaping of the chars in the frontend

kerem commented

2026-02-27 08:15:47 +03:00

Author

Owner

@Normanras commented on GitHub (Mar 31, 2023):

I'm happy to let you guys point me where to start. I can add to the validator, forcing the user to remove the whitespaces.

Given that all my other usernames without whitespaces don't throw the error, that could cover it for the time being.

@Normanras commented on GitHub (Mar 31, 2023): I'm happy to let you guys point me where to start. I can add to the validator, forcing the user to remove the whitespaces. Given that all my other usernames without whitespaces don't throw the error, that could cover it for the time being.

kerem commented

2026-02-27 08:15:47 +03:00

Author

Owner

@pixelrazor commented on GitHub (Apr 1, 2023):

If you want to tackle it:
The form lib uses this to validate https://github.com/Keats/validator

It should just be a simple addition to the user_details_form. The form struct should already have a validator on email iirc. You can probably validate with does_not_contain

@pixelrazor commented on GitHub (Apr 1, 2023): If you want to tackle it: The form lib uses this to validate https://github.com/Keats/validator It should just be a simple addition to the user_details_form. The form struct should already have a validator on email iirc. You can probably validate with does_not_contain

kerem commented

2026-02-27 08:15:47 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 10, 2023):

I fixed the underlying encoding issue, but we still need the username validation. Let's do that as part of #239 though.

@nitnelave commented on GitHub (Apr 10, 2023): I fixed the underlying encoding issue, but we still need the username validation. Let's do that as part of #239 though.