[SOLVED] Custom roles with permissions not working in v4.0.3 and v4.2

[mayvelous]

I have…

• [ x ] Checked the logs and found some error logs below:

CleanupDefunctSiloEntries operation is not supported by the current implementation of IMembershipTable. Disabling the timer now.

Showing error: prompt=none was requested but user is not authenticated

JWT token validation error: IDX10501: Signature validation failed. Unable to match key: \nkid: \u0027[PII is hidden.

Error validating JWT\n{\n \u0022ClientId\u0022: \u0022squidex-frontend\u0022,\n \u0022ClientName\u0022: \u0022squidex-frontend\u0022,\n \u0022ValidateLifetime\u0022: false\n}","@logMessage":"{\n \u0022ClientId\u0022: \u0022squidex-frontend\u0022,\n \u0022ClientName\u0022: \u0022squidex-frontend\u0022,\n \u0022ValidateLifetime\u0022: false

End session request validation failure: Error validating id token hint\n{\n \u0022SubjectId\u0022: \u0022unknown\u0022,\n \u0022Raw\u0022: {\n \u0022id_token_hint\u0022: \u0022***REDACTED***\u0022,\n \u0022post_logout_redirect_uri\u0022

Error processing end session request Invalid request",“error”:“Invalid request”,“app”:{“name”:“Squidex”,“version”:“4.2.0.0”,“sessionId”:“e632846c-5d00-42d4-9f49-fc1b04d9a0d8”},“web”:{“requestId”:"|8a69e932-4cfbf5ee0ee59176.",“requestPath”:"/connect/endsession",“requestMethod”:“GET”},“timestamp”:“2020-04-23T01:51:37Z”,“category”:“IdentityServer4.Endpoints.EndSessionEndpoint”}

I’m submitting a…

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

Current behavior

Below issues are tested and found on version 4.0.3 and 4.2.
Permission label undefine issue is only on v4.2 custom roles. Default systems roles’ permission labels display fine in v4.2.

1. v4.2 specific Custom role permission labels are not displaying when a user is assigned to the role. See attached images:
   Permission labels without assign users:
   
   
   
   Permission labels with assigned users
   
   
2. Custom roles with permission * wildcard on sections no longer work
3. User cannot perform allowed action(s) (read/create/update) if assigned with custom roles
   Content list(if available) is displaying as ‘- No Value -’. Redirect to forbidden page when create/read the content. See attached image.
   
4. Custom roles permissions cannot be updated

Expected behavior

1. Custom roles which has assigned users should display permissions labels instead of undefine in v4.2
2. Wildcard on sections should work as per documentation https://docs.squidex.io/02-documentation/concepts/permissions#defining-permissions.
   eg: contents.xxx.* , contents.pages|posts|articles.*
3. When a user is assigned with a custom role to restrict access for specific content schema management, the user should be able to access allowed content section and should be able to perform allowed action(s)
4. Should be able to update custom roles with/without users permissions, not just delete them while it has no users assigned

Minimal reproduction of the problem

Provided there are multiple content schemas available, create a new custom role to only allow one schema management. eg. page content.
Role test 1 permissions:

• contents.page
• assets

Role test 2 permissions:

• contents.page.*

Role test 3 permissions:

• contents.page.read
• contents.page.create
• contents.page.update
• contents.page.delete
• contents.page.update.partial
• contents.page.version.create
• contents.page.version.delete

Role test 4 permissions:

• contents.page
• all of the permissions above from test 3

Environment

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

Version:

• 4.0.3.0
• 4.2

Browser:

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

Others:

Similar issues reported on: [SOLVED] Custom roles issue
Also it’ll be really great if there’s permission to NOT allow using ^ as mentioned in the documentation or able to hide schema or settings sections as it’s really not right to let user who should only see one content schema section able to view the whole site schemas in the schema section including json, settings tabs.

[Sebastian]

The problem with not showing the permissions is solved.

For the other problem: Can you check how requests are made?

If you see the ID of the schema in the URL instead of the name, then it is solved as well in dev.

[mayvelous]

I see to view the list page it uses schema name but to open each item uses ID.
Create action uses ID as well.
The fix is in v2.2.2? I’m trying to upgrade to that version.
How come 4.2 to v2.2.2

[mayvelous]

I think you made mistake in version numbers? v2.2.2 update messed up the app, seems to be the old one and doesn’t have api/info path anymore. Cannot see any schema/content sections. Rolling back now.
Could you confirm which build includes the permission labels fix please?
Thanks.

[Sebastian]

2.2.2 contains a small fix based on 2.2.1, you can try dev

[Sebastian]

I think this is fixed, pretty sure. I just tested it and cannot reproduce it.

[mayvelous]

I tested in my local with dev version and confirmed it’s working. Thank you!
But when I check /api/info it’s showing 3.0.0.0.
Since it’s dev version we cannot release yet.
Could you estimate when would be the next stable release?

[Sebastian]

The version is coming from the tags so far…therefore no real version.

I can release it on monday I think.

[mayvelous]

Thanks. Yes I used “dev” tag so I was expecting “dev” to show up when I check /api/info url but it’s coming out as “3.0.0.0” No worries, I’ll wait for Monday release. Thanks again.

[mayvelous]

Thanks for the 4.3 release. Confirmed permission issue has been solved.
I wasn’t aware when a schemaA has relation field to another schemaB, we have to give permission (at least read permission) to schemaB as well.
There’s a bug on read permission. The user with read permission can change the content status. eg. Published to Draft. Ticket created: Can change publish status in Read permission
Just thought I mention here about read permission able to change status here first.
Anyways thanks again for the release.