Bandwidth Issues – HELP WANTED

[spinfly]

Hey all,

Hoping I can solicit the help of the lovelinetapes.com community to help get the site back on track. Any web developers/engineers want to help me tackle this?

Here’s the problem: I have a folder full of hundreds of GB of MP3’s that power the site. I have no problem letting site visitors:

a) play the MP3’s using the player embedded on each show page, or
b) download them using the download link on each show page.

With either of the two above methods, I am able to prevent people from accessing more than 1 file a minute, which seems like a fair balance between letting users enjoy shows and reducing bandwidth.

What I previously had up on the site a few months ago was doing all of this perfectly, but what I was NOT blocking were people using scripts to automatically access/download the shows with direct links. Scripts like this one:

http://userscripts.org/scripts/review/131328

Shit like that was killing my bandwidth. When bandwidth skyrockets, my host gets angry and forces me to spend more money. Money out of my pocket. And I’m not willing to spend hundreds of dollars a month to keep this site going. Sorry.

So I need to come up with a solution to block scripts like this and prevent direct access to the MP3 directory on my server by any method other than the two described above. I’ve tried screwing around with the .htaccess file to redirect all .mp3 calls, but that disables the player I have on each show page. I’ve tried playing with session and cookie variables, but I can’t seem to get things working right.

Over the past few months, I’ve been so bogged down with real work that I haven’t been able to get this figured out. So now I’m reaching out.

Anyone out there want to help?

[DCTBSBN]

Signed up to hopefully start getting the ball rolling on this fix. I love your site and am so grateful that a place like this is here. Listening to this show gave me a lot of comfort in dark times. Comfort from both the callers and the hosts.

ANYWAYS…

I’m looking at your html and I’m seeing in the markup. That’s what this user script is latching onto. Is there anything stopping you from putting the js in a separate file? The script you linked to is able to find the route: /objects/recordings/NTE0ZjJhOTk.mp3′ and on a click take you directly to that folder. it bypasses any checks you do or bandwidth use and knows the file’s name, because it’s in the markup, and in the url for the show (?id=966&h=NTE0ZjJhOTk). Since you’ve already got your routes all set up to use the id that directs people to your folder, it’s going to take a bit of a revamp to hide this away.

What are your thoughts?

[spinfly]

Thought of externalizing the JS, but the problem is that some of the code that goes into the JS needs to be generated dynamically when the server spits out the page.

Currently, I’ve implemented a hacky .htaccess solution so that direct links to the show MP3s will not work. Try it:

http://www.lovelinetapes.com/objects/recordings/NTE0ZjJhOTk.mp3

You’ll see that it forwards you to check.php instead of accessing the MP3 directly. The problem is that the real validation that I need isn’t being done by check.php. People who can figure out the real file links (which wouldn’t be hard) can STILL access the files with direct links.

Somehow, I need the player (and the download link on each page) to be able to access the MP3s ONLY AFTER certain PHP validation has been run. I was able to get this working for downloads, but for the player, it’s tricky, as the player needs a direct link to an MP3 to function correctly. A link to a PHP file instead of an MP3 will break the player.

Just found some new ideas with a Google search. Will try those out this evening.

[Laynard]

Looks like the site is back to normal now. Yay!!!!

Does that mean that this issue has been resolved? If not, I may be able to help out.

Thanks,
Jason

[rickygw]

Have you thought about pointing your audio tags / download links to a PHP script? That script’s job is to validate the user and return mp3 binary data instead of HTML. If the user doesn’t validate, return a 404.

This has a couple benefits.
– first, you get to write any PHP validation you want before actually delivering the file. if user doesn’t pass, you dont return the contents of the file
– you can put your MP3s in a directory on your server that isnt publicly accessible. that means it would be physically impossible for anyone to link directly to an MP3 file. only way to get to them is through code you’ve written

The drawback is that it will slow the performance of your server down if you get a TON of normal traffic. This is because all MP3 data is now being delivered by the PHP module/executable. It would take a good amount of traffic to make a noticeable slow down (not sure how much traffic you get).

You may already be doing this but if not, it might be worth looking into and I can help with that.

Thanks for this site. It gets me through good times and bad!

[spinfly]

@rickygw Yep, that’s the ideal solution, and it does work great for downloads. The problem is that the player I’m using doesn’t like going to a PHP file to pull the MP3… Might have to invest in a new player that can obfuscate files names/paths.

[Author]

Posts