Add sensible limit to user name inputs #2935

New Issue

OVERLORD · 2026-02-05T05:47:22+03:00

OVERLORD commented

2026-02-05 05:47:22 +03:00

Originally created by @ehumphrey-payments on GitHub (Aug 2, 2022).

Describe the Bug

Alt title: Missing input validation on Name

When a user is editing their profile under the "Edit Profile" section, extremely long names are accepted by the system, even as long as 792 characters. This starts causing system issues for the logged-in user, who won't able to use the system anymore due to HTTP 500 errors. Doesn't seem to have any impact for other users.

Steps to Reproduce

Log in as any user. Ideally, have a backup admin user than can edit profiles.
From the user dropdown, select Edit Profile.
Under Name, enter these 231 characters:

AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA

Save your changes. The changes are saved successfully with an HTTP 200. The username change will be successful and show in the audit log.
BookStack will return an HTTP 500 error on every page.

Expected Behaviour

The user does not get an HTTP 500 error when accessing BookStack.

Optional:

Instead of being allowed to have an absurdly long name, the user receives an error when the new name length exceeds a certain length.
Add the permission ability to disallow users from editing their own name or their own user as a whole
- Particularly useful if the user's name is sourced from an SSO provider and therefore not requiring editing
Allow maximum name length to be configurable

Screenshots or Additional Context

No response

Browser Details

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0

Exact BookStack Version

v22.06.2

PHP Version

7.4.26

Hosting Environment

LinuxServer container on Ubuntu 22.04 LTS virtual machine
LinuxServer MariaDB container
Nginx 1.22 as reverse proxy

Originally created by @ehumphrey-payments on GitHub (Aug 2, 2022). ### Describe the Bug **Alt title: Missing input validation on Name** When a user is editing their profile under the "Edit Profile" section, extremely long names are accepted by the system, even as long as 792 characters. This starts causing system issues for the logged-in user, who won't able to use the system anymore due to HTTP 500 errors. Doesn't seem to have any impact for other users. ### Steps to Reproduce 1. Log in as any user. Ideally, have a backup admin user than can edit profiles. 2. From the user dropdown, select Edit Profile. 3. Under Name, enter these 231 characters: > AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAA 4. Save your changes. The changes are saved successfully with an HTTP 200. The username change will be successful and show in the audit log. 5. BookStack will return an HTTP 500 error on every page. ### Expected Behaviour * The user does not get an HTTP 500 error when accessing BookStack. Optional: * Instead of being allowed to have an absurdly long name, the user receives an error when the new name length exceeds a certain length. * Add the permission ability to disallow users from editing their own name or their own user as a whole * Particularly useful if the user's name is sourced from an SSO provider and therefore not requiring editing * Allow maximum name length to be configurable ### Screenshots or Additional Context _No response_ ### Browser Details Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Firefox/102.0 ### Exact BookStack Version v22.06.2 ### PHP Version 7.4.26 ### Hosting Environment * LinuxServer container on Ubuntu 22.04 LTS virtual machine * LinuxServer MariaDB container * Nginx 1.22 as reverse proxy

OVERLORD added the 🐛 Bug label 2026-02-05 05:47:22 +03:00

OVERLORD closed this issue

2026-02-05 05:47:23 +03:00

OVERLORD commented

2026-02-05 05:47:26 +03:00

@ssddanbrown commented on GitHub (Aug 4, 2022):

Thanks for the report @ErikHumphrey, I agree the some extra length-validation could be useful here, outside of the database field length limitation.

In regards to the http 500 errors, do you have any information on these? Perhaps from any of the error logs in your stack.
During my testing I was not able to replicate such errors, even when using the linuxserver.io container setup.

@ssddanbrown commented on GitHub (Aug 4, 2022): Thanks for the report @ErikHumphrey, I agree the some extra length-validation could be useful here, outside of the database field length limitation. In regards to the http 500 errors, do you have any information on these? Perhaps from any of the [error logs](https://www.bookstackapp.com/docs/admin/debugging/#error-log-file) in your stack. During my testing I was not able to replicate such errors, even when using the linuxserver.io container setup.

OVERLORD commented

2026-02-05 05:47:32 +03:00

@ssddanbrown commented on GitHub (Aug 9, 2022):

Limit set within commit 4209f27f1a. Still fairly high (100 chars) but don't want to go too low as don't want to break existing usages.

I'll assume the 500 was something else at play, and re-name then close this issue off.

@ssddanbrown commented on GitHub (Aug 9, 2022): Limit set within commit 4209f27f1acabfccff0c2dea08f8e151ed82144f. Still fairly high (100 chars) but don't want to go too low as don't want to break existing usages. I'll assume the 500 was something else at play, and re-name then close this issue off.

OVERLORD commented

2026-02-05 05:47:35 +03:00

@ehumphrey-payments commented on GitHub (Aug 10, 2022):

Thanks! Pentester and myself tried to reproduce the issue on the same, old version recently and weren't able to either; sorry.

@ehumphrey-payments commented on GitHub (Aug 10, 2022): Thanks! Pentester and myself tried to reproduce the issue on the same, old version recently and weren't able to either; sorry.

OVERLORD commented

2026-02-05 05:47:39 +03:00

@ssddanbrown commented on GitHub (Aug 10, 2022):

@ErikHumphrey No worries! Thanks for confirming though!

@ssddanbrown commented on GitHub (Aug 10, 2022): @ErikHumphrey No worries! Thanks for confirming though!

OVERLORD referenced this issue

2026-02-05 10:24:22 +03:00

[PR #2935] [MERGED] Allow to use DB tables prefix #6096

Sign in to join this conversation.