On Wed, Jan 10, 2018 at 01:32:00PM -0500, anish10dec wrote:

Hi there,

> Let me explain the complete implementation methodology and problem
> statement
>
> URL to be protected
> http://site.media.com/mediafiles/movie.m3u8
>
> We are generating token on application/client side to send it along with
> request so that content is delivered by server only to authorized apps.

There's your design problem.

Don't generate the token on the client side. Have the client do whatever
it takes to convince the server that it is authorised, and have it ask
for a current link to the movie.m3u8 content.

Then the server uses the server-secret and whatever other things are
relevant to create a secure_link url, possibly including an expiry time
based on the server-clock, are returns that url to this client.

Then when any client tries to access that url after the server-clock
expiry, they will fail. And if any client tries to access that url before
the expiry time, it will be allowed only if the secure_link matches -- if
it includes something like REMOTE_USER or a $cookie that was only given to
one client, then only something with the matching values will succeed; if
it was just based on things within the url, then every thing will succeed.

> Please let know if there is a way to protect the content in this scenario.

No.

In your scenario, the client decides the expiry time, and creates a url
that the server will honour until then.

(And it can create a new url that will expire a day later, and the server
will honour that too.)

Anyone who requests that url before that expiry time will be given
the content.

So in your scenario, you would probably have to write your own
securish_link module which checks that the expiry time is in the future,
but not too far in the future. And then decide how much slop to allow,
in case someone has the clock wrong on their client.

You're probably better off starting with a different design.


(As an aside: this might also resolve the question in
https://forum.nginx.org/read.php?2,275668 -- when the client has no idea
what the server-secret is, there is no need to have updated clients for
a different server-secret.)


Good luck with it,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx