Restricting access to directory... with conditions

October 5, 2009 6:35 PM

How do I restrict access to a directory on my web site but still allow an audio streamer program to access the files? For instance, I want to put my mp3s in the audio directory but I want anyone going to mydomain.com/audio to not be able to download the tracks. The audio player being used is JW Player if that makes any difference. Thanks!
posted by You Should See the Other Guy to computers & internet (16 comments total)

If you put an empty called called index.html in the audio folder, it will prevent others from at least seeing the files.
posted by whiskeyspider at 6:45 PM on October 5

Either:

a) Drop an index.html file in
b) Disable Directory Indexing on your web server (see server docs or tell us which server)

Note this won't stop somebody from saving the file they stream -- the DRM problem. You can be really tricky by trying to add some code to check user agent, but really, stopping directory indexing will keep most of what you want.
posted by effugas at 6:47 PM on October 5

whiskeyspider, they can still view the code on the page with the audioplayer and with that get the directory and filename and grab it that way.

effugas, the server is with Dreamhost. I think it's Apache.
posted by You Should See the Other Guy at 6:53 PM on October 5

As long as you tell JWPlayer enough to play the URL, a malicious user can use that URL to download the audio file by copying and pasting the URL into their browser, or a command line utility like curl/wget. Yes, you could check user agent, but same malicious user could defeat that check by sniffing his/her own internet traffic to see what user agent the player used, and telling curl/wget to spoof that user agent.
posted by Alterscape at 6:55 PM on October 5

There's no way for you to know what program on your client's machine is using a file unless it has its own secure communications exchange protocol. If JW PLayer is using HTTP, then anything else that uses HTTP will look, or can look, exactly the same and there's no way for you on the server to tell them apart.

The only way you can secure your data in the way you want is to create your own player program which your listeners would have to download and run. And I don't know about anyone else, but there's no way in hell I would download your arbitrary program and let it on my machine just to listen to your music. That sounds like a fantastic way to risk get infected with all kinds of malware.
posted by Chocolate Pickle at 7:08 PM on October 5

I was hoping there was a way for the server / directory to sense where the request was coming from (a file on the server in the same directory) and simply deny access to the file from any foreign request. I thought maybe htaccess could do it or there'd be some other solution. Am I mistaken?
posted by You Should See the Other Guy at 7:12 PM on October 5

I think the problem is that the request isn't really 'coming from a file on the server', but on code running on the visitor's machine.
posted by dcjd at 7:21 PM on October 5

I was hoping there was a way for the server / directory to sense where the request was coming from (a file on the server in the same directory) and simply deny access to the file from any foreign request. I thought maybe htaccess could do it or there'd be some other solution. Am I mistaken?

I'm afraid you are. There's no way for the server to determine that in HTTP.
posted by Chocolate Pickle at 8:16 PM on October 5

I thought maybe ... there'd be some other solution. Am I mistaken?

Yes, about several things.

First, there is no real difference between streaming and downloading. Streaming is just rate-limited downloading with some degree of security by obscurity. Anything you stream, I can save if I want to.

Second, there is no difference at all between streaming via HTTP from a web server and downloading.

From this it follows that if you're distributing content from a web server and you don't want a directory of it available, then doing anything more sophisticated than installing a blank index.html file will be a sheer waste of everybody's time.
posted by flabdablet at 8:17 PM on October 5

For example, you might consider doing clever tricks with cookies and dynamic filename generation, such that the filename you end up handing off to the music player will become invalid after it's been opened and closed once; a client's music player might find itself streaming mydomain.com/audio/ba23bpbir7.flv which is actually a dynamically generated alias for mydomain.com/audio/cool-music-track.flv, whose existence remains hidden by virtue of the blank index.html.

But all I have to do to defeat this is get to your web app via a transparent proxy server that grabs all incoming files as they're fetched by HTML, and these are freely available for all platforms. In fact installing a proxy server is easier than fooling about with packet sniffers and curl and wget and whatnot, and would be the no-brainer way to capture any stream you used HTML to deliver.

If you're streaming via something other than HTML (perhaps RTMP) then I need to work a little harder: I sniff my own network connection with Wireshark to find out what RTMP stream you're opening, then I pause your embedded player and re-open the same stream with mplayer. From your streaming server's point of view, this is no different from using your embedded player's own seek control to restart the stream. If you disable stream restarting, you've also disabled seeking and annoyed your non-downloading users.

Unless your content has heavyweight DRM and is restricted to being played only on devices that enforce such DRM, it's going to get redistributed, to some extent, by means beyond your control. That's just the nature of digital data.
posted by flabdablet at 8:42 PM on October 5

Aight, then. Thanks!
posted by You Should See the Other Guy at 8:53 PM on October 5

Another question: is there a way to keep google out of there so at least the mp3s don't turn up in searches?
posted by You Should See the Other Guy at 11:03 PM on October 5

Sure: put

User-agent: *
Disallow: /audio/

in a file called robots.txt in the root directory of your site.
posted by nicwolff at 11:32 PM on October 5

If there's a blank index.html file in the directory, your server won't show what's in there to anybody, Google spider included. So provided there are no static HTML pages elsewhere that link to the files inside, they won't show up in Google searches.

The Google spider also respects robots.txt, if I recall correctly.
posted by flabdablet at 11:36 PM on October 5

And as regards your previous question

I was hoping there was a way for the server / directory to sense where the request was coming from (a file on the server in the same directory) and simply deny access to the file from any foreign request. I thought maybe htaccess could do it or there'd be some other solution. Am I mistaken?

You can't easily do this, because according to this support-forum thread, JW Player doesn't send a Referer header, so we have to allow any request that doesn't supply that header, which means that any user not following a link could paste the URL into their browser and download the file.
posted by nicwolff at 11:45 PM on October 5

Referer headers are trivial to spoof in any case.
posted by flabdablet at 12:35 AM on October 6