Hello,
After upgrading to 14.7 and 14.8, I definitely lost some batch permissions.
My drop folders and batch uploads stopped working because the batch process is not allowed to access the acls because of this kind of errors:
Log file is not ready: Error: The access to service [accessControl->list] is forbidden
Is there a way to restore the permissions tables or attributes without affecting the production servers ?
Can it be done via the api console ?
Any help would be greatly appreciated !
David Eusse
jess
November 27, 2018, 11:04am
2
Hi @david.eusse ,
Have you confirmed that when trying to make the accessControl->list() request manually [passing a KS that belongs to the same partner] the same response is returned [forbidden]?
In terms of how the permission mechanism works, please see my post here:
Hi @cbwilkes ,
First, you’re welcome.
As for your question, luckily, the service permissions mechanism is very modular so that can be changed with relative ease.
There are three DB tables involved:
permission
permission_item
permission_to_permission_item
To properly illustrate the relations, I’ll walk you through the queries and actual results on my own ENV, then you can apply them same to yours.
BEFORE YOU START MANIPULATING THESE TABLES, PLEASE BACKUP ALL 3 TABLES.
We start by locating …
Following that, you will be able to understand the relations between the different permission tables.
The original question was about the partner->register() action; you should use this query as a starting point instead:
mysql> select * from permission_item where param_1='accesscontrol' and param_2='list'\G
Cheers,
Hello Jess,
After checking my tables and comparing to my dev server where it works (same setup), I noticed that this permission was not present:
| 45 | PARTNER_-1_GROUP_*_PERMISSION | Partner -1 permission for group * | Partner -1 permission for group * |
After inserting it this is what I get but still doesn’t work:
MariaDB [kaltura]> select id,name,friendly_name, description from permission where id in (121,222,45);
±----±------------------------------±----------------------------------±----------------------------------+
| id | name | friendly_name | description |
±----±------------------------------±----------------------------------±----------------------------------+
| 45 | PARTNER_-1_GROUP_*_PERMISSION | Partner -1 permission for group * | Partner -1 permission for group * |
| 121 | ACCESS_CONTROL_BASE | Access control profiles access | |
| 222 | KMC_READ_ONLY | KMC read only access | |
±----±------------------------------±----------------------------------±----------------------------------+
Where else do I need to look or do I need to clean any cache ?
It’s weird that ACCES_CONTROL_BASE is present.
Thanks again for any tips,
David
Hello Jess,
I checked through the test console and noticed that partner -1 (batch) is not allowed to list the access controls. However, he can list other attributes like categories. Nor can partners 0 and -2.
I suppose partner -1 is the one that needs to have these permissions granted. Am I right ?
Regards,
David
FIxed !!
One additional permission was needed. In case anyone else gets into the same problem: These are the permissions for the batch services:
MariaDB [kaltura]> select id,name,friendly_name, description from permission where id in (121,222,181,143);
±----±----------------------------------------±-------------------------------±-------------------------------------------------+
| id | name | friendly_name | description |
±----±----------------------------------------±-------------------------------±-------------------------------------------------+
| 121 | ACCESS_CONTROL_BASE | Access control profiles access | |
| 143 | ALWAYS_ALLOWED_FROM_INTERNAL_IP_ACTIONS | No session permission internal | Permission without session from internal servers |
| 181 | CONTENT_MANAGE_DISTRIBUTION_SEND | Distribution submit | |
| 222 | KMC_READ_ONLY | KMC read only access | |
±----±----------------------------------------±-------------------------------±-------------------------------------------------+
Regards,
David