Shelf-title ending in 'public': breaks 'edit shelf', breaks 'delete shelf'? #2821

New Issue

OVERLORD · 2026-02-05T05:21:00+03:00

OVERLORD commented

2026-02-05 05:21:00 +03:00

Originally created by @labor4 on GitHub (May 30, 2022).

Describe the Bug

This is a strange one.

I can reconstruct:
Any shelf title, ending in "public" will be unable to edit later on, also unable to delete.
Resulting only in a 404 error, with no laravel log entries.

Could this be true?

Steps to Reproduce

create shelf "hello-public"
create shelf "hello2-public"
create shelf "huh-public-ending"
create shelf "public-ending"
edit/delete shelf "hello-public" -> ERROR
edit/delete shelf "hello2-public" -> ERROR
edit/delete shelf "huh-public-ending" -> OK
edit/delete shelf "public-ending" -> OK

Expected Behaviour

shelf titles to be "waterproof" 😀

Screenshots or Additional Context

No response

Browser Details

No response

Exact BookStack Version

BookStack v22.04.2

PHP Version

8.0

Hosting Environment

Ubuntu 18 LTS, Plesk 18

Originally created by @labor4 on GitHub (May 30, 2022). ### Describe the Bug This is a strange one. I can reconstruct: **Any shelf title, ending in "public" will be unable to edit later on, also unable to delete.** Resulting only in a 404 error, with no laravel log entries. Could this be true? ### Steps to Reproduce - create shelf "hello-public" - create shelf "hello2-public" - create shelf "huh-public-ending" - create shelf "public-ending" - edit/delete shelf "hello-public" -> ERROR - edit/delete shelf "hello2-public" -> ERROR - edit/delete shelf "huh-public-ending" -> OK - edit/delete shelf "public-ending" -> OK ### Expected Behaviour shelf titles to be "waterproof" 😀 ### Screenshots or Additional Context _No response_ ### Browser Details _No response_ ### Exact BookStack Version BookStack v22.04.2 ### PHP Version 8.0 ### Hosting Environment Ubuntu 18 LTS, Plesk 18

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

OVERLORD closed this issue

2026-02-05 05:21:09 +03:00

OVERLORD commented

2026-02-05 05:21:14 +03:00

@ssddanbrown commented on GitHub (May 30, 2022):

Hi @labor4, Thanks for reporting.
I think though this will be specific to your webserver/environment configuration.
A quick test on our demo instance could not reproduce the first case.

Are you able to share any webserver config at all?

Note: If you normally have /public/ within your normal BookStack URL this likely reflects an unsupported and possibly insecure setup.

@ssddanbrown commented on GitHub (May 30, 2022): Hi @labor4, Thanks for reporting. I think though this will be specific to your webserver/environment configuration. A quick test on [our demo instance](https://demo.bookstackapp.com/books/bookstack-demo-site/page/logging-in-to-the-demo-site) could not reproduce the first case. Are you able to share any webserver config at all? Note: If you normally have `/public/` within your normal BookStack URL this likely reflects an unsupported and possibly insecure setup.

OVERLORD commented

2026-02-05 05:21:18 +03:00

@labor4 commented on GitHub (May 30, 2022):

Haha, you got me, by mentioning a different problem of the DOCROOT.
It was my setup!

Thanks for checking.

Yes I had a problematic .htaccess on DOCROOT (below /public):

RewriteEngine on
RewriteCond %{HTTP_HOST} ^MYDOMAIN$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.MYDOMAIN$
RewriteCond %{REQUEST_URI} !public/
RewriteRule (.*) /public/$1 [QSA,L]

The error was here: RewriteCond %{REQUEST_URI} !public/
The Rule obviously snapped in at the URL .../shelves/hello-public/edit or even .../shelves/public/edit

Corrected:

RewriteEngine on
RewriteCond %{HTTP_HOST} ^MYDOMAIN$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.MYDOMAIN$
RewriteCond %{REQUEST_URI} !^/public/
RewriteRule (.*) /public/$1 [QSA,L]

But regarding your thought on "possibly insecure":

The reasoning behind having DOCROOT at the install DIR is that I expect Plesk to be in line with its backup procedures.

Would you say that the above .htaccess approach would satisfy the concern?

@labor4 commented on GitHub (May 30, 2022): Haha, you got me, by mentioning a different problem of the DOCROOT. It was my setup! Thanks for checking. Yes I had a problematic .htaccess on DOCROOT (below /public): ``` RewriteEngine on RewriteCond %{HTTP_HOST} ^MYDOMAIN$ [NC,OR] RewriteCond %{HTTP_HOST} ^www.MYDOMAIN$ RewriteCond %{REQUEST_URI} !public/ RewriteRule (.*) /public/$1 [QSA,L] ``` The error was here: ```RewriteCond %{REQUEST_URI} !public/``` The Rule obviously snapped in at the URL ```.../shelves/hello-public/edit``` or even ```.../shelves/public/edit``` Corrected: ``` RewriteEngine on RewriteCond %{HTTP_HOST} ^MYDOMAIN$ [NC,OR] RewriteCond %{HTTP_HOST} ^www.MYDOMAIN$ RewriteCond %{REQUEST_URI} !^/public/ RewriteRule (.*) /public/$1 [QSA,L] ``` But regarding your thought on "possibly insecure": **The reasoning behind** having DOCROOT at the install DIR is that I expect Plesk to be in line with its backup procedures. Would you say that the above .htaccess approach would satisfy the concern?

OVERLORD commented

2026-02-05 05:21:25 +03:00

@ssddanbrown commented on GitHub (May 30, 2022):

Would you say that the above .htaccess approach would satisfy the concern?

It really depends on the wider context of your setup.
In general if any files/folders, outside of the BookStack public/ folder, are exposed/accessible in public web space then this significantly increases surface area and techniques for exploitation/vulnerability.
Really, only the public folder should be exposed as the web/document root. If any parent folders are exposed then that is not ideal.

@ssddanbrown commented on GitHub (May 30, 2022): > Would you say that the above .htaccess approach would satisfy the concern? It really depends on the wider context of your setup. In general if any files/folders, outside of the BookStack `public/` folder, are exposed/accessible in public web space then this significantly increases surface area and techniques for exploitation/vulnerability. Really, only the `public` folder should be exposed as the web/document root. If any parent folders are exposed then that is not ideal.

OVERLORD commented

2026-02-05 05:21:27 +03:00

@labor4 commented on GitHub (May 30, 2022):

Ok fair arguement. I will check if I can .htaccess can answer all of these.

As a note: I have seen suites using .htaccess with deny from all strategies in every "private" subdir, to answer this. In one case the index.php script itself checked for their existence/working condition, and would deny normal usage until the problem was resolved. I dont remember which appliance this was.

@labor4 commented on GitHub (May 30, 2022): Ok fair arguement. I will check if I can .htaccess can answer all of these. As a note: I have seen suites using .htaccess with ```deny from all``` strategies **in every "private" subdir**, to answer this. In one case the index.php script itself checked for their existence/working condition, and would deny normal usage until the problem was resolved. I dont remember which appliance this was.

OVERLORD commented

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

@ssddanbrown commented on GitHub (May 30, 2022):

Since the cause of the original issue is know I'll close this off.

I would advise correctly setting the document root where possible instead of using workarounds.
Any reasonable hosting system should allow setting of this.

@ssddanbrown commented on GitHub (May 30, 2022): Since the cause of the original issue is know I'll close this off. I would advise correctly setting the document root where possible instead of using workarounds. Any reasonable hosting system should allow setting of this.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#2821