Securing URLs with the Secure Link Module in NGINX

[Andrew Andonopoulos]

Hi Francis,

The idea of moving MD5 and Time after the first directory is good.
So with this option i will not have to worry modifying the manifests.

If i use this URL:  /vod/MD5/TIME/hls/directory/files

The locations will be like this?

location ^~ /vod/"
  secure_link $the_md5,$the_time;
  secure_link_md5 "some-secret $the_directory $secure_link_expires";
  if ($secure_link = "") { return 403; }
  if ($secure_link = "0") { return 410; }
  rewrite ^ /hls/$the_directory/$the_file;

location ^~ /hls/"
  internal;
  proxy_pass http://s3test.s3.amazonaws.com<http://s3test.s3.amazonaws.com/>;


Also i will need to capture the variables:
Then I would use "map" to set variables $the_md5, $the_time,
$the_directory, and $the_file from the incoming request.

Do you have an example how to write the map with the appropriate regex?

Thanks
Andrew
________________________________
From: nginx <nginx-bounces at nginx.org> on behalf of Francis Daly <francis at daoine.org>
Sent: Monday, June 17, 2019 11:39 AM
To: nginx at nginx.org
Subject: Re: Securing URLs with the Secure Link Module in NGINX

On Mon, Jun 17, 2019 at 08:17:51AM +0000, Andrew Andonopoulos wrote:

Hi there,

> I would like to add the secure link in each m3u8 and ts file but can't modify the files on the fly with the free nginx version, i think nginx plus have this capability ? (receive fmp4 and deliver manifests on the fly)
> https://www.nginx.com/products/nginx/streaming-media/

If nginx plus resolves all of your issues quickly and easily, then
"use nginx plus" would seem to be the straightforward option.

I think that only you can assess whether nginx plus does do what you
want, because you have not actually said what exactly you want, as far
as I can see, in any of these mails.

> What you would suggest in case i want to use secure link for all the files?

I would probably redesign the urls that I was going to advertise, so
that people request things like

  /play/MD5/TIME/directory/file

(From your example - "directory" is "justin-timberlake", and "file" is
"playlist.m3u8" or "Justin_Timberlake_640_360_600.m3u8" or, presumably,
"something.ts". "/play" is a mostly-arbitrary prefix so that I can do
other things on the same server -- it can probably be empty if this
server is dedicated to these streams.)

Then I would use "map" to set variables $the_md5, $the_time,
$the_directory, and $the_file from the incoming request.

I would want the MD5 calculation to include the directory name, but not
the file name, so that a single MD5 value will "cover" all files in the
directory, but will not cover other directories.

Then if everything is ok, rewrite to an internal location that does the
proxy_pass to get the real content.


So - in "location ^~ /play/" (which handles all /play/* requests), I would
use something like

  secure_link $the_md5,$the_time;
  secure_link_md5 "some-secret $the_directory $secure_link_expires";
  if ($secure_link = "") { return 403; }
  if ($secure_link = "0") { return 410; }
  rewrite ^ /hls/$the_directory/$the_file;

And in "location ^~ /hls/" (which handles all /hls/* requests), I would use

  internal;
  proxy_pass http://s3test.s3.amazonaws.com;


Then you decide what TIME you want, and calculate the suitable MD5
for each directory that you care about. (You can include user-specific
things in the calculation too -- just make sure that your secure_link_md5
directive and your external link-creating utility use the same patterns.)

Then try to use those links, and see what works and what fails.


For every new directory, or new expiry time, you calculate the new link
to the playlist.m3u8 and advertise that.

Note that I have not tested any of this; so if you do get a
confirmed-working config, I'm sure the list will be happy to see it for
future reference.

Good luck with it,

        f
--
Francis Daly        francis at daoine.org
_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20190617/747fcc81/attachment.html>