We have been experiencing some problems with our ACLs, specially with the Country block rules. After a long debug we noticed that problem is related to the player embed which is causing these errors.
We are using a dynamic embed but haven’t been able to catch the problem. In other test pages, using the same embed works well.
The main site uses React and I don’t know if that might be part of the problem. Could it be a CORS related problem ?
We believe the ACL evaulation occurs when executing the load.php process. I’l be glad if someone can give me a short explanation of the ACL execution process so we can debug our problem.
To elaborate more on this issue, we’v found that on some cases, we got a 404 when requesting the manifest and we get some X-kaltura headers like this:
x-kaltura-acp: 13 0
x-kaltura-app: exiting on error 3 - entry restricted due to access-control
x-kaltura: error-3
But, on some other cases, we still get the Country Not Permited message but there is no request to the manifest.
We need to determine exactly which request is the one that gets processed by kaltura to evaluate the ACL so we can then construct a proper cache Key into our CDN in order to serve the proper object to each country.
If some one from Kaltura could give us this information (@jess ??), it would be great for us.
We’v been doing trial and error tests for more than a month without any real outcome yet.
The easiest way to debug this would be to run a HTTP sniffer [you can use the “dev tools” component most modern browsers have these days and inspect the requests a “play” event triggers]. Look at the API requests issued and their responses. Each response includes a X-Kaltura-Session ID. You can use that ID to trace the requests in /opt/kaltura/log/kaltura_api_v3.log. Be sure to set the writers.*.filters.priority.priority directives in /opt/kaltura/app/configurations/logger.ini to 7 and to reload Apache before commencing, so that the logs contain all the needed debug info.
Is this api call related to the geoblock functioning ?
GET /api_v3/index.php?service=stats&apiVersion=3.1&expiry=86400&clientTag=kwidget%3Av2.75.1&format=1&ignoreNull=1&action=collect&event:eventType=5&event:clientVer=2.75.1&event:currentPoint=1321217&event:duration=2642.199&event:eventTimestamp=1556801726622&event:isFirstInSession=false&event:objectType=KalturaStatsEvent&event:partnerId=102&event:sessionId=c068c97b-4f09-f897-6dbd-e90d0b4b53f6&event:uiconfId=23448186&event:seek=false&event:entryId=0_kvims35g&event: …
We are filtering it on our CDN because we are handling the analytics differently. However, we are sending a proper 200 response to the client.
In doing so, we reduce the API CPU needs significantly and the platform becomes very stable under any traffic conditions.