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 to yours.
BEFORE YOU START MANIPULATING THESE TABLES, PLEASE BACKUP ALL 3 TABLES.
We start by locating the relevant ID in the permission_item table:
mysql> select * from permission_item where param_1='partner' and param_2='register'\G
*************************** 1. row ***************************
id: 993
type: kApiActionPermissionItem
partner_id: 0
param_1: partner
param_2: register
param_3:
param_4:
param_5:
tags:
created_at: 2017-06-29 12:17:13
updated_at: 2017-06-29 12:17:13
custom_data: NULL
So, in my case, the ID is 993.
Now, let’s check what permissions are associated with this permission_item_id in the permission_to_permission_item table:
mysql> select * from permission_to_permission_item where permission_item_id =993
-> ;
+------+---------------+--------------------+---------------------+---------------------+
| id | permission_id | permission_item_id | created_at | updated_at |
+------+---------------+--------------------+---------------------+---------------------+
| 2499 | 61 | 993 | 2017-07-18 14:31:57 | 2017-07-18 14:31:57 |
| 2500 | 72 | 993 | 2017-07-18 14:31:57 | 2017-07-18 14:31:57 |
| 2501 | 80 | 993 | 2017-07-18 14:31:57 | 2017-07-18 14:31:57 |
| 2502 | 181 | 993 | 2017-07-18 14:31:57 | 2017-07-18 14:31:57 |
+------+---------------+--------------------+---------------------+---------------------+
So, you can see we have four of these. Let’s see what they are:
mysql> select id,name,friendly_name, description from permission where id in (61,72,80,181);
+-----+------------------------------+----------------------------+----------------------------+
| id | name | friendly_name | description |
+-----+------------------------------+----------------------------+----------------------------+
| 61 | ADMIN_PUBLISHER_MANAGE | Manage publishers | |
| 72 | ALWAYS_ALLOWED_ACTIONS | No session permission | |
| 80 | BASE_USER_SESSION_PERMISSION | User session permission | |
| 181 | WIDGET_SESSION_PERMISSION | Anonymous user permissions | Anonymous user permissions |
+-----+------------------------------+----------------------------+----------------------------+
The one you are interested in getting rid of is ID 72.
Now, you didn’t specify what permissions you would like to enforce but I’ll take an educated guess and assume you’d like the registration of a partner to only be allowed when using a -2 KS [-2 is the Admin Console partner ID].
For that, you will need to:
- Get rid of the ALWAYS_ALLOWED_ACTIONS record:
mysql> delete from permission_to_permission_item where permission_item_id =993 and permission_id=72;
- Locate the ID for PARTNER_-2_GROUP_*_PERMISSION in permission table (in my case it is 218):
mysql> select * from permission where name = 'PARTNER_-2_GROUP_*_PERMISSION'\G
*************************** 1. row ***************************
id: 218
type: 4
name: PARTNER_-2_GROUP_*_PERMISSION
friendly_name: Partner -2 permission for group *
description: Partner -2 permission for group *
partner_id: -2
status: 1
depends_on_permission_names:
tags:
created_at: 2017-06-29 12:16:48
updated_at: 2017-07-03 12:52:17
custom_data: a:1:{s:13:"partner_group";s:1:"*";}
- Insert a corresponding record into permission_to_permission_item:
mysql> insert into permission_to_permission_item values (NULL, 218, 993, NOW(), NOW());
After running these queries, when calling the partner->register() action with anything other than a -2 KS, you should get:
code SERVICE_FORBIDDEN
message The access to service [partner->register] is forbidden
objectType KalturaAPIException
FYI, the defaults are set in this INI:
/opt/kaltura/app/deployment/permissions/service.partner.ini
So, if you ever deploy a DB from scratch, you can just edit this file BEFORE running the configure scripts so you won’t have to make manual adjustments after the deployment is done.
There is one INI file per service.