Hello!

On Fri, Jul 04, 2014 at 09:48:04AM -0400, ura wrote:

> the config i am using is inherited from the designers of the elgg platform
> and i have explored it enough to know most of what it is doing.
> perhaps i need to replace the location block that targets .php files with
> one that explicitly lists all the possible locations of php files instead...
> which would leave the possibility open for the new 'stream' location block i
> am using here.
>
> i was using the internal keyword since i am wanting to do what i can to
> ensure that the video files are only available to site visitors once they
> have passed a security process (handled by php and sql). the site here is a
> social network and all media items have an associated privacy level - so the
> files cannot all be public, which is the origin of these issues. the files
> are held outside of the nginx site root directory for this reason.

Sure. The problem is that you try to "navigate to
www.mysite.tld/stream/blah.mp4", and it won't work if the location
in question is internal.

> > Streaming videos with php is silly, so recommended approach is
> > "Don't do that".
>
> how else can a video be served from a PHP social networking app, where the
> file needs to be 'behind' privacy/security checks?
> wouldn't there need to be some kind of PHP processing just to set up the
> externally accessible path for the video file (after the viewer's
> credentials have been checked)?
> to be clear, i am not saying that the final path for the video is a .php
> file.. the final path would be filename.mp4.. however, the php location
> block is triggered along the processing path anyway - as the config is.

There are more than one way to do security checks. Most obvious
ones is to use either X-Accel-Redirect, or auth_request, or
secure_link.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx