Content comments 'forbidden' with site level permissions

Support
1

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.

squidex.apps.ourappname.comments

or

squidex.apps.ourappname.comments.read
squidex.apps.ourappname.comments.create
squidex.apps.ourappname.comments.update
squidex.apps.ourappname.comments.delete

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.

Environment

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

Browser:

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

Others:
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:

image
image1103×152 33.7 KB

Our full permissions being set at the moment are:

squidex.apps.ourappname.assets
squidex.apps.ourappname.comments
squidex.apps.ourappname.contents.*.read
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.create
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.update
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.update.own
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.changestatus
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.changestatus.own
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.changestatus.cancel
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.changestatus.cancel.own
squidex.apps.ourappname.contents.schema-a|schema-b|schema-c.version.*
squidex.apps.ourappname.history
squidex.apps.ourappname.languages.read
squidex.apps.ourappname.schemas.read
squidex.apps.ourappname.usage

Any guidance would be greatly appreciated!

2

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

3

I just tested it. You also need contributors.read permission.

4

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: https://docs.squidex.io/02-documentation/concepts/permissions#special-permission

Would contributors.read 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).

5

You can find the common permissions here:

1 Like
6

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.

7
  • 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
8

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

9

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.