make downloads work and more securer

Worker Joined: Dec 01, 2008 Posts: 180

First of all we all know protecting our downloads is a vital thing to the majority, so whatever downloads module you are using, if you have leech protection then activate it for the folder your downloads are located in, then within your .htaccess file make sure the ruling #Deny from All is removed and the following is inserted:

RewriteEngine on
RewriteCond ${LeechProtect:/home/******/public_html/modules/Downloads/public/downloads:%{REMOTE_USER}:%{REMOTE_ADDR}:5} leech
RewriteRule .* http://www.yourwebsite.com

Particularly if you use nsn gr downloads and have your downloads in a folder under Downloads/public/..../...., make sure the .htaccess file under your downloads contains the above, or similar if you use different protection.

xx Bless xx

Posted: Wed Feb 18, 2009 7:26 pm

That will not stop leeching fully. The only way to protect your files is to move tham above the public root.

Posted: Wed Feb 18, 2009 7:59 pm

Wouldn't that actually make it easier to leech, as shorter URL's easier to work out, rather than longer extensions, i.e.

mywebsite.com/downloads/..... //* or whatever name of download directory.

or

mywebsite.com/modules/downloads/public/downloads/...../.....

A few years ago i used a online program that used to change a link to a random link, maybe this ability can one day be built into nsn gr downloads as part of RN, i'll let Montego decide.

In the sense that when a URL is written in add download, and save changes is pressed, the link that stores in the database, should randomly change to something different to prevent theft, when being accessed to download.

Or is there anything else i and others could use as protection against download theft?

Your advice is much appreciated.

xx Bless xx

Posted: Wed Feb 18, 2009 8:13 pm

Yes, in theory, renaming the file by generating a long random filename at upload time can be beneficial and it is good practice to do so with anything that is uploaded.

What I meant by 'above the public root' was if for example your downalods directory is in your actually webroot like this;
username/public_html/downloads/
it is better to put your 'downloads' directory here
downloads/public_html/
as nothing can even get to that except the server.

Posted: Wed Feb 18, 2009 8:29 pm

How would i then enter that as a link when adding a download URL to add download?

registered · Posted: Wed Feb 18, 2009 8:36 pm

For security, you really would put the download in a non web-accessible area and then write a script to authenticate and pass the file download as requested. Many commercial scripts do this, but Nuke downloads is essentially the easy way with trivial amount of code. Smile

Posted: Wed Feb 18, 2009 9:16 pm

What about a script that is used to get the download then rename the directory?

registered · Posted: Wed Feb 18, 2009 9:17 pm

BTW, this thread here addresses download leaching and how to stop it with NSN GR Downloads.

http://www.ravenphpscripts.com/postp60755.html#60755

Posted: Wed Feb 18, 2009 9:25 pm

That thread just scares me Smile

Posted: Fri Feb 20, 2009 5:32 pm

Thanks Montego, the go.php modifications were an addition, although my question at hand still seems confusing to me.

Say for instance, if i was to follow the above security measures by Guardian and move my downloads folder under .......mydownloads/public_html/, how would i then write the link in the URL box, when i add downloads in nsn gr downloads, because usually it refers to something above /modules/Downloads/...... doesn't it?

Posted: Fri Feb 20, 2009 6:04 pm

I have mine similar to this:

public_html/public/downloads/*

I have the .htaccess file in there with "deny from all". If you are on Apache, that effectively stops ALL direct linking to any download file you have in there.

Now, since public_html is really the root of my web site, so let us say my download file name is: mydownload.zip. The path I would use within the download set up is this:

/public/downloads/mydownload.zip

The only thing that I cannot do is the "check". But, I'll eventually fix that too. It has not deterred me from using this very effective method for almost 3 years now.

Posted: Fri Feb 20, 2009 6:18 pm

Thanks so much for confirming Montego.

Thats exactly how my setup is now, although i must say, within my public .htaccess file i do have the deny from all rule, but in my downloads folder i am using leech protect rewrite method without the deny from all, does this matter not having this?, because as i stated previously having the deny from all rule in the downloads folder caused a conflict over no downloads being served.

xx Bless xx