HorizonForumsone horizon
Log inSign up

[ms] · Est. May 2002

Music madethis place,we just kept itgoing...

One durable person. One social graph. Many communities—and every way people speak, share, listen, write, gather and remember.

Forums / General Yakkity Yak

Stealing our bandwith

55 durable postsStarted 2005-06-06Latest 2005-06-13
#435620Post 41 of 55

Re: Stealing our bandwith

[quote=BalkanBeat]hi[/quote] [quote=BalkanBeat]hi[/quote]

Greetings and welcome to the board, but we heard you the first time. Oh, and don't steal our bandwidth.

#435641Post 42 of 55

Re: Stealing our bandwith

FeralCode, Puffy, it might sound easy to design a system that enables only mn registered users to get the downloads (a user/ip or ip table), but if you deal mostly with dynamic ip's and want to be able to resume downloads, it gets pretty complicated to maintain that system and also educate the users. Just imagine the amount of complaints and questions the mods would be dealing with if the current system is already a challenge for some users.

#435644Post 43 of 55

Re: Stealing our bandwith

i totaly agree ... but tell me a better way to get rid of this badwith stealing ... like someone can post how many posts r necesary to get acces to downloads and after he gets the links bye bye ... u dont c him again ...

#435647Post 44 of 55

Re: Stealing our bandwith

I guess there is already a check on some server log for the referrer data for every file requested and that's how you find out about the links being posted elsewhere. Enforcing that referrer data is a good/easy thing to do, but it can get spoofed easily. You are tackling a good amount of stealers, cause most people won't know how to cheat the referrer data, but it's still not perfect.

If the guys haven't done something already and they're posting this, I'd think it's because they went through all the options and didn't find a way to stop it (yet) without creating more trouble.

#435708Post 45 of 55

Re: Stealing our bandwith

IP check is certainly the wrong way to handle this. It needs to be done with the cookies.

The hiding of direct link is not very complicated. Instead of posting your direct link, you post download.php?file=filename.mp3, then download.php can handle all the permissions (any restrictions, like login to forum and minimum posts, etc.)

Here is also a small article about hot linking: [url]http://www.developerz.com/php_hotlinking.htm[/url]

#435739Post 46 of 55

encode the download urls using php scripting IMO.

also disallow hotlinking from external sites.

problem solved.

#435743Post 47 of 55

hotlinking is disallowed, problem is there IS a way to safely bypass this if you know how to.

#435782Post 48 of 55

Re: Stealing our bandwith

Use a script to feed the download to the user. For a start, if they don't have a valid session cookie for the board then don't let them download.

Although it would mean keeping a transaction log, which wouldn't be too hard, you could keep a tab on the number of downloads to each user. Have a cheeky script that checks the logs for the current sets, every 30 minutes for anything irregular, and email the admins for the bannage.

#435785Post 49 of 55

Re: Stealing our bandwith

E, check your PM - I sent you a possible solution - what I like to call (even to my work mates) a "frisky Solution"

It WILL work.

hehe. f.

#435857Post 50 of 55

Re: Stealing our bandwith

Jesus you guys are thinking way too hard about this, I have implemented a system on 4four that works like a dream:

First, stick all of your mp3s into a single directory called '00000000'

Then create a single table in a MySQL database, with two columns, one for the mix name, and one for the mix filename.

So for example, mix filename would be:

CraigRichards_LiveAtFlame_2005.mp3

The mix name would be:

CraigRichardsLiveAtFlame2005

Then write a script that takes a single query parameter called 'name', ie:

[url]http://www.MercuryServer.com/mix.aspx?name=CraigRichardsLiveAtFlame2005[/url]

(I use ASP.NET, PHP would be fine also)

Firstly the script checks that the referrer is a valid mercuryserver domain (this stops people copying the hot-link)

The name parameter is the mix name, the script then uses this to look up the filename.

Next the script builds the full link to the real file:

mp3folder = "00000000"

"http://www.mercuryserver.com/mp3s/" + mp3folder + "/CraigRichards_LiveAtFlame_2005.mp3"

Once the script has done all the validation it should then redirect to a page which exposes the live-link to the file or redirects to it (redirecting can be problematic for some browsers).

Now for the clever bit?

Each day you should run a process on the server to rename the folder 00000000 to a GUID, then get your script to insert the GUID instead of 00000000 when building the link. This means that if anyone steals your links they are only good for one day, which will remove the biggest problem of links sites. Obviously people can still grab it externally for a day, but this is such a small issue compared to having a link live for days.

There is one issue with this system, and that is that if someone is downloading from you at the time of the folder rename then their download will fail. I personally don?t see this as an issue, as they can just try again. And if you do it when your board is at its quietest then you won?t have too many people hit. At the end of the day it?s a free service, so no one can really complain about it ;)

#435863Post 51 of 55

Re: Stealing our bandwith

Thats a great solution paul... :-)

but with all due respect all of you are missing the entire point: to make sure no one steals your propietary data/assets - dont make it available to the world. Its just that simple. The solution I sent to -e- makes sure that NO ONE that shouldnt be getting the files gets their filthy paws on them. period. and its simple as cake, if programmed correctly.

f.

#435869Post 52 of 55

Re: Stealing our bandwith

Well if it's foolproof please post the details here, I'd be interested in implementing it for 4four :)

If it involves streaming from a DB blob or from a file but using a script to feed the data then I wouldn't be interested. As that starts sucking away at server resources (due to the fact that the scripts need to be running for the duration of the download). That's not really acceptable on a busy messageboard, with potentially lots of downloads occuring at once.

Paul

#435870Post 53 of 55

Re: Stealing our bandwith

Sure, here's a pretty simple solution:

Basically the problem is that the files they wish to share are publically accessible thru a hotlink. If youre a good enough hacker - you can spend about 55 seconds and easily get the direct link of the assets here on MN. I wont share how to do this here publically and cause more headaches to them. :)

What you can do to protect yourselves: Put all your download assets in a non-public_html folder. Something that is NOT on the www symlink. When you want to throw them out to a user for download, simply change your code to send an fopen() with that file_path. Simple. Secure. Easy!

Thats it. That means that ONLY a person with the proper credentials (ie Auth Token/password) can get the file - and since the file is NOT open to the public - ie, its not in the www folder, there is NO such thing as a direct HTTP link - even for a day!

I use this solution on the [url]www.winamp.com[/url] website. php rocks! f.

#435923Post 54 of 55

Re: Stealing our bandwith

I'm not a PHP expert, but doesn't doing an fopen imply that the script will be live for the duration of the download? It's something I definitely want to avoid.

#435924Post 55 of 55

yo f, sorry I wasnt online much to read your PM but I just got the chance to do it. Actually am not that good with php, am just learning the ropes. I can "tweak" code a bit but no way in hell can I write any of it.

So I guess I'm stuck

-e-

Log in to reply