Owner of playlist cannot delegate permissions

#1

I have a 1.8.2 CMS and we are slowly migrating to the server from a 1.7.x and we are having some issues with permissions…
To be clear, all material is being recreated. Nothing is moved or imported.

Once a user have created a layout, they cannot change the permissions of it. The only reponse from the system is a “Access Denied” popup.

I have tried the cascade thing and changing the owner to no avail.

Does anyone have any suggestions? I’m running out of ideas and the amount of users and groups are amassing now. Current number of displays is about 50 and i think there will be as many more coming in over the next months.

Halp.

#2

It would be best to confirm that the issue persist on the current version (1.8.5), there was an issue with changing the owner of the layout (fixed in 1.8.3 I believe).

If you user creates a new layout, then that user should be able to grant permissions on it to other users.

If the same would persist for you on 1.8.5, could you please let me know the exact permissions you have assigned to that user (owner of the layout) so I can try and recreate it locally please?

#3

I have done a quick test on my testserver and realized i have forgotten one small detail.
You see, it worked on that one…

Then i realized, im running shiboleth on the main server. Could that be an issue?

And yes, i will upgrade this week.

#4

Confirmed that it is a SAML issue.
I have logs to show the issue too, should i post them here?

#5

You can, however if it contains any sensitive data, it would be better to send it over private message or an email to Spring Signage support please.

#6

There is nothing that anyone can do harm with there, i hope, since it is behind firewalls…
This is what the debug log says when a user tries to change permissions on a newly created layout.
It’s a little messy and you might want to copy it to notepad++ or something to make sense of it.
“frely247” is the username of the user in question.

 Loading 3. All Objects = 0 [] {"uid":"31d9e14","method":"GET","route":"/user/permissions/form/Campaign/66","userId":3}
[2018-02-12 12:12:13] WEB.DEBUG: Checking permissions against the logged in user: ID: 3, Name: frely247, UserType: 3 [] {"uid":"31d9e14","method":"GET","route":"/user/permissions/form/Campaign/66","userId":3}
[2018-02-12 12:12:13] WEB.DEBUG: Route user not viewable [] {"uid":"31d9e14","method":"GET","route":"/user/permissions/form/Campaign/66","userId":3}
[2018-02-12 12:12:13] WEB.DEBUG: Blocked assess to unrecognised page: /user/permissions/form/:entity/:id. [] {"uid":"31d9e14","method":"GET","route":"/user/permissions/form/Campaign/66","userId":3}
[2018-02-12 12:12:13] WEB.DEBUG: Access Denied#0 /var/www/xibo/lib/Middleware/SAMLAuthentication.php(349): Xibo\Entity\User->routeAuthentication('/user/permissio...') #1 [internal function]: Xibo\Middleware\SAMLAuthentication->Xibo\Middleware\{closure}() #2 /var/www/xibo/vendor/slim/slim/Slim/Slim.php(1210): call_user_func_array(Object(Closure), Array) #3 /var/www/xibo/vendor/slim/slim/Slim/Slim.php(1356): Slim\Slim->applyHook('slim.before.dis...') #4 /var/www/xibo/vendor/slim/slim/Slim/Middleware/Flash.php(85): Slim\Slim->call() #5 /var/www/xibo/vendor/slim/slim/Slim/Middleware/MethodOverride.php(92): Slim\Middleware\Flash->call() #6 /var/www/xibo/lib/Middleware/Actions.php(142): Slim\Middleware\MethodOverride->call() #7 /var/www/xibo/lib/Middleware/Theme.php(35): Xibo\Middleware\Actions->call() #8 /var/www/xibo/lib/Middleware/SAMLAuthentication.php(385): Xibo\Middleware\Theme->call() #9 /var/www/xibo/lib/Middleware/CsrfGuard.php(62): Xibo\Middleware\SAMLAuthentication->call() #10 /var/www/xibo/lib/Middleware/State.php(117): Xibo\Middleware\CsrfGuard->call() #11 /var/www/xibo/lib/Middleware/Storage.php(47): Xibo\Middleware\State->call() #12 /var/www/xibo/lib/Middleware/Xmr.php(36): Xibo\Middleware\Storage->call() #13 /var/www/xibo/vendor/slim/slim/Slim/Slim.php(1302): Xibo\Middleware\Xmr->call() #14 /var/www/xibo/web/index.php(124): Slim\Slim->run() #15 {main} [] {"uid":"31d9e14","method":"GET","route":"/user/permissions/form/Campaign/66","userId":3}
#7

The permissions system requires that you user has access to the “user” page (as does things like change password, etc).

It looks to me like your user does not have that page.

#8

Dear oh dear, that was it?
I wonder why it worked on my labserver. Oh well… Thanks a million for that tip.

Worked like a charm.
We didnt think we needed that since the password is in the AD and not local.

#9

No problem - you could argue that we could improve that by having a page specific to “permissions”, but for now we’ve bundled it in with general user functions.

Pleased its working!