views:

63

answers:

1

I have an Apache password-protected directory filled with text files and movie files. Currently, I load the contents of the text files using cURL, passing the username and password information with CURLOPT_USERPWD. For the movies, I set the OBJECT and EMBED src's to http://username:[email protected]/file.mov. In both cases, the username and password are pulled from $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'], respectively. If that does not work, then the user is prompted to provide new credentials with a generic HTTP auth pop-up.

Is there are a more proper way to do this? Or is embedding password-protected movies just a buggy/bad idea?

The above method results in two (related?) problems. First, (as far I can tell) randomly, it seems that the username:password@ part is not passed when embedding the movie, and thus the user is forced to enter their credentials again. This rarely occurs, and is only annoying, but would be nice to fix.

Second, this causes Safari under Snow Leopard to crash. Safari, without fail, prompts the user for credentials, then freezes. Non-password-protected movies (or moving the password-protected movies to a non-password-protected directory) load fine. This problem did not exist pre-Snow Leopard, but I haven't tested it on older versions of Safari under Snow Leopard, so it could be one of the recent updates broke it.

NOTE: Moving to another login system (thus negating the issue) sadly is not possible since other programs that use the files require Apache password protection.

+1  A: 

Are you on a secure connection? Otherwise it looks as if the username/password are open to prying eyes?

I would tend towards having a server side script (eg. serve_content.php) that manages the serving of your protected content. And link to it something like:

src="serve_content.php?id=1234"

serve_content.php checks that the user is logged in. Identifies the file from the passed id (which masks the true location of the protected content), so '1234' might be 'mymovie.avi'. And sends the file to the client. eg. using readfile() with the appropriate headers.

The Apache password-protected directory acts to prevent unauthorised direct access. If you were logging your users in by some other method, then no user would be able to access the file directly, only via serve_content.php.

w3d
The Apache password protection is required by other programs, so unfortunately these files will always exist in password-protected directories. :/
mojojojo
@mojojojo That's OK. In fact it's good these files are in a protected directory. The server side script (serve_content.php) is _immune_ to the HTTP Authentication so can read the files directly, but it can still check to make sure the user is authenticated _before_ serving the file.
w3d
@w3d but won't there still be the issue when the QuickTime plugin tries to load the file.mov movie? That is done client-side, so will have to deal with the HTTP authentication, right?
mojojojo
@mojojojo It should not be a problem. The `OBJECT`'s src attribute is now pointing to a server-side script _outside_ of your protected directory, it is not pointing to the protected file directly. The server-side script authenticates the user, reads the file from the protected directory (which is not affected by the HTTP Authentication) and sends it to the client. The client has no concept of where the original file is located, it is simply making a request for a file and as long as it receives an appropriate response with the correct mime-type headers, all _should_ be OK.
w3d
@w3d *smacks forehead* It took me awhile, but I finally understood what you were saying. Thanks a bunch.
mojojojo