Kaltura 12.15 Akamai HD Token not working

1

Hi,

I have just upgraded to Kaltura 12.15 and my Akamai HD delivery profile stopped working (403).

I have the following nginx configuration:

secure_token_akamai $my_token {
key 24616c31707330;
acl “$secure_token_baseuri_comma*”;
}
.
.

serve flavor Secure HLS

            location ~ ^/sechls/p/\d+/(sp/\d+/)?serveFlavor/ {
                    vod hls;
     secure_token $my_token;
    secure_token_types application/vnd.apple.mpegurl;
    secure_token_expires_time 100d;
    secure_token_query_token_expires_time 5m;
    secure_token_uri_filename_prefix index;

                    akamai_token_validate on;
                    akamai_token_validate_key 24616c31707330;
                    akamai_token_validate_uri_filename_prefix index ;

I also defined a delivery VOD profile as follows:
Delivery Profile type: VOD_PACKAGER_HLS
Streamer type: APPLE_HTTP
Supported protocols: http,https
Delivery Profile URL: http://hddev.cdn.net.co/sechls
Tokenizer type: Akamai Secure HD
key: 24616c31707330
Window: 30
Param name: hdnea
Acl Postfix: *

Now I’m getting a 403 and haven’t been able to validate de manifest again.

Maybe Is there something that I need to change on my delivery profile ?

Thanks in advance for any help.

David Eusse

2

Hi @david.eusse,

Firstly, is the value set for internal_ip_range in /opt/kaltura/app/configurations/local.ini correct?
Secondly, what do you see in the Nginx error log [/opt/kaltura/log/kaltura_nginx_errors.log or /opt/kaltura/log/nginx/error_log, depending on whether you’re using Deb or RPM]?

Thanks,

3

Hi Jess,

I don’t get any nginx errors. I only get a 403.

This the actual nginx access log:

65.167.61.190 - - [15/May/2017:11:28:33 -0500] “GET /sechls/p/109/sp/10900/serveFlavor/entryId/0_moiqktzz/v/2/flavorId/0_5yjaq3pg/name/a.mp4/index.m3u8?hdnea=st=1494865712~exp=1494866012~acl=/sechls/p/109/sp/10900/serveFlavor/entryId/0_moiqktzz/v/2/flavorId/0_5yjaq3pg/name/a.mp4/index.m3u8*~hmac=b84050a8ff19013a77ff3227b11d236cc5349bf5e6a7c2f827715bc992846903 HTTP/1.0” 403 319 0.000 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.1 Safari/603.1.30” “-” - “-” “hddev.cdn.net.co” 18551 - - 1856 “-” “65.167.61.190” “-” “hddev.cdn.net.co” “-” 2

This was my log before the upgrade:

65.167.61.190 - - [10/May/2017:11:34:54 -0500] “GET /sechls/p/101/sp/10100/serveFlavor/entryId/0_uat17ana/v/2/flavorId/0_meipblmv/name/a.mp4/encryption.key?hdnea=ip=65.167.61.190~st=1494434092~exp=1494520492~acl=/sechls/p/101/sp/10100/serveFlavor/entryId/0_uat17ana/v/2/flavorId/0_meipblmv/name/a.mp4/*~hmac=3f0a140bf3f838295b0eff5b1436f274d492effc3bfbedec8e608baf781e0a3d HTTP/1.0” 200 519 0.001 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8” “-” - “-” “hddev.cdn.net.co” 20360 - - 1862 “-” “65.167.61.190” “-” “hddev.cdn.net.co” “max-age=8640000” 3923

I also noticed that the IP address does not show anymore on the URL when added to the secure_token_akamai {} configuration.

Is it possible to debug the debug the token hash in order to confirm that it’s working ?

Thanks again for your help,

David

4

I forgot,

My internal Ip range is still open.

internal_ip_range = 0.0.0.0-255.255.255.255

Regards,

David

5

Jess,

After doing an old fashioned rpm fiddling I finally noticed that I get the 403 error with the latest kaltura-nginx-1.12.0-3.x86_64.rpm package.

It does work with kaltura-nginx-1.12.0-2.x86_64.rpm and kaltura-nginx-1.10.3-5.x86_64.rpm using the same config files and delivery profiles.

Unfortunately, I can’t review the nginx code and provide a fix but at least I can report this bug.

Regards,

David

6

Hi David,

The Nginx VOD module is also FOSS so you can review it if you wish:) It’s here:

That said, since I am not experiencing the same issue, I may need access to your ENV to further debug. Can you message me in private?

Thanks,

7

Hi Jess,

I wish my c and c++ skills had not vanished with time…

But I have already visited and reviewed all the relevant kaltura git repos and docs in order to find the problem and help fix it if possible.

I’l be glad to let you check my servers and settings if it helps to improve the platform. I can send you a ssh access via email if it’s fine for you (maybe I need to learn how to send a private message on this forum) :frowning:

I have just a very stupid question. I noticed that the manifest URLs are somehow been cached but I haven’t been able to find where they are kept. I have flushed memcached, erased /opt/kaltura/app/cache. cleaned my nginx frontend caches, etc, but the URL doesn’t change if, for instance, I make a configuration change… How do I do ?

Regards,

David

8

Hi David,

RE cache: did you reload Apache?
As for access info, please email me at jess.portnoy kaltura.com.

Thanks,

9

Hi Jess,

I waited and upgraded to 12.16 and can confirm that I can’t make kaltura-nginx 1.12.04 validate the akamai token.
It works for kaltura-nginx 1.12-02.

I double checked all my settings and removed all caches and frontends. I even checked that the token was working (just in case) and it blocks the key if for isntances, I change my origin IP address.

I’l send you and access so you can have a look.

Thank you,

David Eusse

10

Hi David,

I didn’t get your email, perhaps I missed it?
At any rate, I believe your issue stems from changes made in this pull request:

akamai_token_validate on;

Should now be set to:

akamai_token_validate           $arg___hdnea__;

and:

akamai_token_validate_strip_token on

Should be:

akamai_token_validate_strip_token __hdnea__;

We also updated both READMEs with new configuration examples:


Let me know should you have additional questions,

11

Hi Jess,

Thank you for your answer. I was out of office but I’ll test again my settings and let you know.

Regards,

David

12

Hi David,

Hope you had a nice vacation:) Do let me know.

13

Hi Jess,

It finally works ! Thank you.

I am testing now the latest release (12.19)

I’l post if I find any issues.

Regards,

David

14

Welcome, David. Glad to hear we’re good:)