Steps to reproduce:
1. Create a group with the minimal set of roles required to add an event: ROLE_ADMIN_UI, ROLE_UI_EVENTS_VIEW and ROLE_UI_EVENTS_CREATE
2. Try to add an event
1. Add Event->Metadata cannot be edited
2. Add Event->Access Policy does not work (once 1 fixed)
3. Workflow will fail at WOH snapshot (once 1 & 2 fixed)
So the event is not created.
1. No read access to event metadata (required to see what metadata fields can be edited)
2. No read access to ACL tempaltes
3. If event is an upload, snapshot step fails due to resources under /asset/assets/* being forbidden (403)
Users of groups with sufficient roles (ROLE_UI_EVENTS_CREATE) should be able to create events.
Hi Duncan, I've just checked
<sec:intercept-url pattern="/assets/**" method="GET" access="ROLE_ADMIN, ROLE_OAUTH_USER, ROLE_USER" />
This does not resolve the problem on r/4.x for an unprivileged user. Can you confirm this?
I can confirm that adding this line will still not allow an user to successfully pass the snapshot operation. But we can not see the described problems under 1 and 2. Perhaps because our users have more roles for dealing with events and ACLs.
Yes, as @langr states, only whitelisting the roles for that endpoint doesn't resolve this issue. Although, note that the whitelisting still is necessary for Jetty to offload the request to the /assets/ endpoint.
The follow on issue is that, in AssetManagerWithSecurity.java:107, the call `isAuthorized(mkAuthPredicate(mpId, READ_ACTION))` always returns as false for non-admin users, even when users have the required privileges (as I understand, roles = privileges) to perform the action.
When checking my logs, `mkAuthPredicate(mpId, READ_ACTION)` runs a db query. I'll update this comment shortly with the actual query.
Ruben's query was 40 levels deep, I had one of 110 levels deep.
I think the problem is that the asset manager tries to load the ACL for the media package which fails (see log file). It therefore will fallback to the default ACL which is not providing access for any user that does not have ROLE_ADMIN (or the tenant admin role).
But that is a hypothesis (although the log message saying that the ACL of the media package could not be loaded makes it likely...)