Printable View
Read back...I added. It can halt a server by exceeding. Granted I think Remus supplies the space but even he may be held to limits (maybe not). Someone was attacking with that mindset though.
Everyone has run into a webpage with that error showing (exceeded limit). That is the kind of thing that causes it :)
I totally understood you Chris I just don't understand the mindset of wanting to do that.
Steve
The strange part is that "attack" is related to a single file:Quote:
Originally Posted by w.brants
Steve Reynolds's "multipage dynamic content".
:smoov:
I gave up wondering long ago. There are just these types of people out there.
I think they attacked that one because it's number one on the list. Easy to repetitively hit the way we have it setup. He didn't have to scroll each time to select it or page through anything. It was a convenient file so to speak :)
Chris, I did both front and backend (PHP / MySQL).
The problem with a download protection is that it also might affect people who want to download a few different items and mean no harm or want to restart a download because something went wrong.
Maybe an IP block mightbe a solution if it occurs again from the same IP range.
The counter is already designed to only count downloads that are fully completed. That user did download 53 megabyte so I think he/she was going for a bandwidth exceed.
Definitely. Dirty little tactic.Quote:
Originally Posted by w.brants
It's Wilberts movie. It's his to fix his way within his scope.
Well, fortunately the limit is much higher.
I could implement a daily maximum per ip address. A cronjob could clear it once a day so it won't take up any time once implemented. Do you think such measures are required and if so, what daily maximum should be fair.
Edited out for lack of interest. It's Wilberts movie. It's his to fix his way within his scope.
As long as you have done the load once - can't you work out what the url for the file was and just hit that over and over without going through the movie?
I tried it but I won't put the URL here. It would take 2 mins to write a program to hammer that.
Cheers
Steve
EDITED out by me. He's on his own.
but the path isnt obfuscated I worked it out in less that a minute
Steve
Then add that the list of things to do.Quote:
but the path isnt obfuscated I worked it out in less that a minute
And here was I feelin so proud that you were doing so well!!!! ha ha :pQuote:
Originally Posted by swrzzzz
must go, need get in out of this Rio sun its a killer!!!!!! :smoov:
Just goes to prove what we always say here in Stoke, pays to keep your backends covered!
I will implement a restriction on how much someone can download in a short period of time. As for obfuscating the download url, I don't see a real advantage. Swf is an open file format so the decoding routine could always easily be traced and broken. You don't even have to have swf knowledge for that. A network monitor will do.
Every solution so far I thought of isn't secure. Http and post headers can be forged, network traffic can be monitored. If someone really wants to do harm they will find a way I'm afraid.
Sure I could implement some problems like displaying a graphic that shows a code that has to be entered before a download etc. but that will also affect the majority of the people that means no harm.
Ok. You do whatever you think is best Wilbert. It's your source, your design and your backends so who better than you to decide anything.
I hope it's solved now.Quote:
Originally Posted by Chris_Seahorn
I added some restrictions.
A good idea is to remove all the FUN files, to compress them and to upload the ZIP files.Quote:
Originally Posted by w.brants
The FUN file (in fact a TEXT file) is a waste of bandwidth for everyone.
Of course, starting with KM 5.6, FUN files are compressed by default.
But until then ...
Wanted to mention that you might want to double check that. A user can initiate and then cancel a download and drive up the totals......still.Quote:
The counter is already designed to only count downloads that are fully completed. That user did download 53 megabyte so I think he/she was going for a bandwidth exceed.
Since we recently were debating the need for Flash 8 exports...it's fitting to mention that tracking the oncomplete status of a download is an F8 nicety.
http://livedocs.macromedia.com/flash...=00002210.html
The current download routine acts (and is flawed as mentioned above) like previous Flash versions were.