Bug: Custom role on restricted book #82

New Issue

OVERLORD · 2026-02-04T16:37:13+03:00

OVERLORD commented

2026-02-04 16:37:13 +03:00

Originally created by @nwalke on GitHub (Mar 29, 2016).

I created a custom role with nothing checked under "Asset Permissions" or "System Permissions" as I want to set this role to only access one book. I then created that book, went to "Restrict", checked "Restrict this book" and checked "View", "Create", "Update" for the role. I clicked save restrictions.

A user assigned that role is able to see the book, sees links to create chapters and pages, but gets an error when clicking either of those links. If I go back to the "Restrict" page for that book, the "Restrict this book" check mark is still there, but my line of checkmarks for my custom role is gone.

Looking in the database I see the correct role ID under restrictions:

MariaDB [bookstack]> select * from restrictions;
+----+-----------------+-------------------+---------+--------+
| id | restrictable_id | restrictable_type | role_id | action |
+----+-----------------+-------------------+---------+--------+
| 13 |               3 | BookStack\Book    |       4 | view   |
| 14 |               3 | BookStack\Book    |       4 | create |
| 15 |               3 | BookStack\Book    |       4 | update |
+----+-----------------+-------------------+---------+--------+

The error the user with the custom role ( id 4 shown above) got was "You do not have permission to access the requested page".

I was running this on the master branch.

Originally created by @nwalke on GitHub (Mar 29, 2016). I created a custom role with nothing checked under "Asset Permissions" or "System Permissions" as I want to set this role to only access one book. I then created that book, went to "Restrict", checked "Restrict this book" and checked "View", "Create", "Update" for the role. I clicked save restrictions. A user assigned that role is able to see the book, sees links to create chapters and pages, but gets an error when clicking either of those links. If I go back to the "Restrict" page for that book, the "Restrict this book" check mark is still there, but my line of checkmarks for my custom role is gone. Looking in the database I see the correct role ID under restrictions: ``` MariaDB [bookstack]> select * from restrictions; +----+-----------------+-------------------+---------+--------+ | id | restrictable_id | restrictable_type | role_id | action | +----+-----------------+-------------------+---------+--------+ | 13 | 3 | BookStack\Book | 4 | view | | 14 | 3 | BookStack\Book | 4 | create | | 15 | 3 | BookStack\Book | 4 | update | +----+-----------------+-------------------+---------+--------+ ``` The error the user with the custom role ( id 4 shown above) got was "You do not have permission to access the requested page". I was running this on the master branch.

OVERLORD added the 🐛 Bug label 2026-02-04 16:37:13 +03:00

OVERLORD closed this issue

2026-02-04 16:37:23 +03:00

OVERLORD commented

2026-02-04 16:37:44 +03:00

@ssddanbrown commented on GitHub (Mar 30, 2016):

@nwalke Evening, I've attempted to replicate your setup, Using both MySQL and MariaDB, but I'm having trouble seeing some of the issues you've mentioned.

At the moment, As part of how the permission system has been set up, the role permissions are the master permissions then the entity (Book/Chapter/Page) level permissions are then checked. This means that if a role does not have update permissions at a role level but does have update permissions at a book level they still won't be able to update within that book since the role permissions override. Your issue has made me realise this is wrong. Entity level permission should override and allow access over the role permissions for use cases such as yours. I've been seeing the entity permissions as 'Restrictions' (Preventing Access) rather than 'Permissions' (Allowing and Preventing).

Luckily this is really easy to change (Just one line, app/helpers.php, line 60) but I also want to go through and change the the wording from 'Restrictions' to 'Permissions' in all areas and add some text on the entity permission pages to explain things a little. I'd also want to fully check this to ensure the change won't have any holes. I'll hopefully change this tomorrow and send out a bugfix release.

Right, Sorry for the above ramble, back to the issues I cannot replicate:

A user assigned that role is able to see the book, sees links to create chapters and pages

Users in that role currently should not be able to see those links at all (Due to the above) so there looks to be something else at play here. Did the user in that role refresh the browser after the permissions were changed?

If I go back to the "Restrict" page for that book, the "Restrict this book" check mark is still there, but my line of checkmarks for my custom role is gone.

This is very odd. Your database records are as expected so I'm not sure why this is not being reflected in the UI. By saying 'my line of checkmarks for my custom role is gone' are you saying they are not checked for do you mean the whole role has disappeared?

@ssddanbrown commented on GitHub (Mar 30, 2016): @nwalke Evening, I've attempted to replicate your setup, Using both MySQL and MariaDB, but I'm having trouble seeing some of the issues you've mentioned. At the moment, As part of how the permission system has been set up, the role permissions are the master permissions then the entity (Book/Chapter/Page) level permissions are then checked. This means that if a role does not have update permissions at a role level but does have update permissions at a book level they still won't be able to update within that book since the role permissions override. Your issue has made me realise this is wrong. Entity level permission should override and allow access over the role permissions for use cases such as yours. I've been seeing the entity permissions as 'Restrictions' (Preventing Access) rather than 'Permissions' (Allowing and Preventing). Luckily this is really easy to change (Just one line, app/helpers.php, line 60) but I also want to go through and change the the wording from 'Restrictions' to 'Permissions' in all areas and add some text on the entity permission pages to explain things a little. I'd also want to fully check this to ensure the change won't have any holes. I'll hopefully change this tomorrow and send out a bugfix release. Right, _Sorry for the above ramble_, back to the issues I cannot replicate: > A user assigned that role is able to see the book, sees links to create chapters and pages Users in that role currently should not be able to see those links at all (Due to the above) so there looks to be something else at play here. Did the user in that role refresh the browser after the permissions were changed? > If I go back to the "Restrict" page for that book, the "Restrict this book" check mark is still there, but my line of checkmarks for my custom role is gone. This is very odd. Your database records are as expected so I'm not sure why this is not being reflected in the UI. By saying 'my line of checkmarks for my custom role is gone' are you saying they are not checked for do you mean the whole role has disappeared?

OVERLORD commented

2026-02-04 16:37:47 +03:00

@nwalke commented on GitHub (Mar 30, 2016):

To answer your last question, the checkmarks are cleared but the role is still there.

I'll wait for the fix tomorrow before trying to get the user to recheck the link display issue.

Thanks for the explanation, and I agree that seems backwards and would MUCH prefer it the other way. Definitely looking forward to that!

@nwalke commented on GitHub (Mar 30, 2016): To answer your last question, the checkmarks are cleared but the role is still there. I'll wait for the fix tomorrow before trying to get the user to recheck the link display issue. Thanks for the explanation, and I agree that seems backwards and would MUCH prefer it the other way. Definitely looking forward to that!

OVERLORD commented

2026-02-04 16:37:57 +03:00

@ssddanbrown commented on GitHub (Mar 31, 2016):

Hi @nwalke, I've merged the changes into both the release and master branches now. Let me know if you're still seeing some bugs about.

@ssddanbrown commented on GitHub (Mar 31, 2016): Hi @nwalke, I've merged the changes into both the release and master branches now. Let me know if you're still seeing some bugs about.

OVERLORD commented

2026-02-04 16:38:01 +03:00

@nwalke commented on GitHub (Mar 31, 2016):

Permissions seem to be better now, the user is not able to create things where he shouldn't and the links are gone.

I'm still seeing the line of checkboxes get emptied when I go back to the book permissions page: http://i.imgur.com/QKvuSGx.gifv

The permissions definitely are applying because the user was able to create a page under this book.

The user is still in the role with no default permissions, but they're allowed to view everything. Now that the permissions have been flipped around, I think the default should probably be view nothing.

@nwalke commented on GitHub (Mar 31, 2016): Permissions seem to be better now, the user is not able to create things where he shouldn't and the links are gone. I'm still seeing the line of checkboxes get emptied when I go back to the book permissions page: http://i.imgur.com/QKvuSGx.gifv The permissions definitely are applying because the user was able to create a page under this book. The user is still in the role with no default permissions, but they're allowed to view everything. Now that the permissions have been flipped around, I think the default should probably be view nothing.

OVERLORD commented

2026-02-04 16:38:10 +03:00

@ssddanbrown commented on GitHub (Mar 31, 2016):

@nwalke Thanks for the GIF, Seriously useful. Unfortunately I still cannot work it out. I saw you're using OSX so I tried out the checkboxes on my iPad as well as in a chrome/firefox/safari OSX instance on BrowserStack but I could not replicate that issue. When you inspect those check boxes do they have the checked="checked" attribute set?

I agree with your last point about having a default with no view permissions since that would enable the ability to have a 'whitelist' permission approach. I've opened a separate issue, #92, for this. Since that will require some database changes for a smooth upgrade it'll be in the next release rather than as a bug fix release.

@ssddanbrown commented on GitHub (Mar 31, 2016): @nwalke Thanks for the GIF, Seriously useful. Unfortunately I still cannot work it out. I saw you're using OSX so I tried out the checkboxes on my iPad as well as in a chrome/firefox/safari OSX instance on BrowserStack but I could not replicate that issue. When you inspect those check boxes do they have the `checked="checked"` attribute set? I agree with your last point about having a default with no view permissions since that would enable the ability to have a 'whitelist' permission approach. I've opened a separate issue, #92, for this. Since that will require some database changes for a smooth upgrade it'll be in the next release rather than as a bug fix release.

OVERLORD commented

2026-02-04 16:38:13 +03:00

@nwalke commented on GitHub (Mar 31, 2016):

Trying Chrome on Windows now, same issue. When I look at the inputs, there is no checked="checked".

@nwalke commented on GitHub (Mar 31, 2016): Trying Chrome on Windows now, same issue. When I look at the inputs, there is no `checked="checked"`.

OVERLORD commented

2026-02-04 16:38:18 +03:00

@ssddanbrown commented on GitHub (Apr 3, 2016):

@nwalke Thanks for letting me know, Definitely an app issue then. I've simplified the logic for whether the checkboxes should be checked, to prevent any extra interference. This update has been applied on the master branch.

Let me know if that fixes the issue.

@ssddanbrown commented on GitHub (Apr 3, 2016): @nwalke Thanks for letting me know, Definitely an app issue then. I've simplified the logic for whether the checkboxes should be checked, to prevent any extra interference. This update has been applied on the master branch. Let me know if that fixes the issue.

OVERLORD commented

2026-02-04 16:38:23 +03:00

@nwalke commented on GitHub (Apr 5, 2016):

Still seeing the issue: http://i.imgur.com/CtRMy1h.gif

My user's full name in our bookstack instance is "Nick Walke". It says that it's being updated by the user that created the book, and I know he isn't using it. Hopefully the GIF helps.

@nwalke commented on GitHub (Apr 5, 2016): Still seeing the issue: http://i.imgur.com/CtRMy1h.gif My user's full name in our bookstack instance is "Nick Walke". It says that it's being updated by the user that created the book, and I know he isn't using it. Hopefully the GIF helps.

OVERLORD commented

2026-02-04 16:38:28 +03:00

@nwalke commented on GitHub (Apr 12, 2016):

Upgraded to the 0.9 release and am still seeing this.

@nwalke commented on GitHub (Apr 12, 2016): Upgraded to the 0.9 release and am still seeing this.

OVERLORD commented

2026-02-04 16:38:31 +03:00

@ssddanbrown commented on GitHub (Apr 13, 2016):

Yeah, Sorry, Not sure what it can be at this stage. Have you definitely been doing a composer install as part of your update process?

Really, It must be something on this line. You could try changing that to:

return $this->restrictions()->where('role_id', '=', $role_id)->where('action', '=', $action)->count() > 0;

to force it to load the restrictions straight from the database in case the restrictions on an entity are sticking around.

@ssddanbrown commented on GitHub (Apr 13, 2016): Yeah, Sorry, Not sure what it can be at this stage. Have you definitely been doing a composer install as part of your update process? Really, It must be something [on this line](https://github.com/ssddanbrown/BookStack/blob/master/app/Entity.php#L73). You could try changing that to: ``` php return $this->restrictions()->where('role_id', '=', $role_id)->where('action', '=', $action)->count() > 0; ``` to force it to load the restrictions straight from the database in case the restrictions on an entity are sticking around.

OVERLORD commented

2026-02-04 16:38:41 +03:00

@nwalke commented on GitHub (May 13, 2016):

This is working now. A couple things I did...

We had super weird errors happening when saving drafts to pages, turns out we were on PHP 5.5 instead of 7 (ended up that the chapter ID being returned for a draft not under a chapter was the string "0" instead of the int 0). I upgraded us to PHP 7 and that was no longer an issue. I also noticed that we hadn't explicitly used UTF8 when creating the database, so I did that as well. One or both of those has fixed this for me.

@nwalke commented on GitHub (May 13, 2016): This is working now. A couple things I did... We had super weird errors happening when saving drafts to pages, turns out we were on PHP 5.5 instead of 7 (ended up that the chapter ID being returned for a draft not under a chapter was the string "0" instead of the int 0). I upgraded us to PHP 7 and that was no longer an issue. I also noticed that we hadn't explicitly used UTF8 when creating the database, so I did that as well. One or both of those has fixed this for me.

OVERLORD commented

2026-02-04 16:38:50 +03:00

@ssddanbrown commented on GitHub (May 13, 2016):

@nwalke Awesome, glad it's now sorted. Hope you get a nice little speed boost with PHP7 😄

@ssddanbrown commented on GitHub (May 13, 2016): @nwalke Awesome, glad it's now sorted. Hope you get a nice little speed boost with PHP7 :smile:

OVERLORD referenced this issue

2026-02-04 22:19:51 +03:00

after upgrade, clicking 'Edit Profile' throws an error - ReflectionException (-1) Class SocialiteProviders\GitLab\GitLabExtendSocialite does not exist #804

Sign in to join this conversation.