Users of non-admin groups cannot create events

Steps to reproduce

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

Actual results:
Various problems:
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)

Expected Results:
Users of groups with sufficient roles (ROLE_UI_EVENTS_CREATE) should be able to create events.


Sven Stauber
January 26, 2018, 9:45 AM

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?

Ruth Lang
January 26, 2018, 10:38 AM

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.

duncan smith
January 26, 2018, 11:17 AM


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, 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.

duncan smith
January 26, 2018, 1:43 PM

Ruben's query was 40 levels deep, I had one of 110 levels deep.

Sven Stauber
January 26, 2018, 1:46 PM


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...)


duncan smith


duncan smith


Non Functioning

Tags (folksonomy)


Fix versions

Affects versions