Content comments 'forbidden' with site level permissions

I have…

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [ ] Bug report
  • [ ] Performance issue
  • [x] Documentation issue or request

Current behavior

When a user with either of the following permission sets clicks on the Comments icon they are shown the Squidex ‘Forbidden’ page.



Expected behavior

User with at least read permission for commetns is shown a blank comments section when there are no comments to display, or is shown the comments if there are some.

Minimal reproduction of the problem

As an administrator give a user permissions to access an App and a Schema with Contents in it, and then also give them the comments Permission.
Note: User is not a Contributor within the App, i.e. not assigned to a Role.


App Name: (Is this important when it is self-hosted?)

  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 7.4.0


  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

I would have said this is a regression but I have no idea if this was working OK with site level permissions when on v6.x as at that point we were more reliant on App Roles, so it could well be that we are not specifying it correctly or that we are missing some other vital permission.

However what we have does seem to match what the code is looking for:

Our full permissions being set at the moment are:


Any guidance would be greatly appreciated!

Have you checked the network tab? Perhaps some other request was rejected…

I just tested it. You also need permission.

AHHA yes just added that and it works! Sorry should have caught that myself as it is quite an obvious error coming through in the console, was just too focussed on the server side.

Out of interest this documentation mentions the special “common” permissions:

Would be one of them? As we are using our own claims we should obviously have those common permissions set too, and I was just wondering where it is you map these so I can ensure we do have them all (means I can easily check them when we update Squidex in case a new one is added).

You can find the common permissions here:

1 Like

Wow so that was a pretty big permission to be omitting! Thanks for the information.

We are also missing:

  • PermissionIds.AppPing
  • PermissionIds.AppRolesRead
  • PermissionIds.AppSearch
  • PermissionIds.AppTranslate

So I wonder if that might cause us trouble down the line…will have a rummage around and see what they control.

  • AppPing is just the ping endpoint to check the api status.

The rest of the permissions are only read permissions or no direct access to the database. The search permission is a general permission to the search system, but inside the search the permissions are further narrowed down.

It is really annoying to check for all permissions in the frontend, so I decided not to check for implicit read permissions. Therefore you might receive the error screen if you do not have permissions.

1 Like

Btw: is there no other way to implement this? e.g. if there would be a hook in your identity provider, you could call the API and just sync the contributors

When we were considering how to handle the UI settings (e.g. hiding UI) we were looking at potentially using App Roles and doing exactly that, but at that time I had zero experience with our application so didn’t know where to start (and current setting of Site Permissions was established)! Perhaps it would be easier to go down that route…might have another look into it.

So in short out identity provider would just map to App Roles.