Can you show me an example link that is returning 404?
Thread Starter
hevenz
(@hevenz)
Thread Starter
hevenz
(@hevenz)
oh and if you want the actual link i’d rather email it instead, i changed the site name and email name ( duh )
Is WP installed in a sub directory?
Thread Starter
hevenz
(@hevenz)
yes it is and everything worked fine until the 1.1.8
Is the sub folder name included in the site URL? For example, when going to your site, do you go to mysite.com/wp-folder-name or do you go to mysite.com?
Thread Starter
hevenz
(@hevenz)
nope the files are outside of public_html in a folder called digital_downloads so the url is /home/sitemane/digital_downloads. As stated this setup worked fine before until the latest update of edd. 🙂
The latest update changed how download files are delivered, which is probably why you’re seeing 404s.
Any particular reason why you are placing them outside of the uploads folder?
Thread Starter
hevenz
(@hevenz)
because of security? anyone with the name of the file itself can easily share the link with another person the absolute link not the key generated by edd. I’m curious as to why you would change that feature as it’s the most secure way to deliver content without it being protected by htaccess?
I don’t understand what you mean. The changes that were made made the files more secure, but in order for EDD to protect them, they must be inside uploads/edd.
Files in any other custom directory will be completely unprotected, unless you add your own security, which, depending on how you do it, could possibly cause problems with EDD serving the downloads.
Thread Starter
hevenz
(@hevenz)
if i move the files from non public view as in outside the public_html folder and move it into my wordpress directory where your uploads folder is now located anyone can dechiper the link and share it with anyone as a direct download.
[video src="http://www.mysite.com/mywpdirectory/wp-content/uploads/edd/filenamehere.mp4" /]
The ONLY other file in this directory is a generic Options -Indexes nested inside your .htaccess file, this will not prevent users from finding these files using say, a spidering program to show the files and folders.
The way you had this set up before worked perfectly and allowed my files to be outside the pubic view ( the best form of protecting these files ) but the changes you’ve made have now led this method useless and using your plugin to direct digital download goods is now insecure.
Make sense?
The method in place now is much more secure than the previous method, which had zero protection.
The Options -Index prevents bots or users from browsing the folders and locating the files. It does not, as you noted, prevent anyone from accessing the file if they know the exact URL, but the exact URL is never given out.
If you can provide a better solution, I’m all ears.
The current method still allows your files to be outside of the root, though I don’t quite understand how that would work here because nothing outside the root is accessible via your site’s URL, ever. The only way that works is if you provide the system an actual file path to the files, but EDD doesn’t (and never has) allowed that.
Thread Starter
hevenz
(@hevenz)
Ok now i’m really lost and sorry if i’m being a pain in your….
but i was calling the files as such :
/home/userfolder/digital_downloads/filenamehere.mp4 under File URL and it was working fantastic as i tested it several times…until the 1.18 update that is.
now you say that it needs to be in the uploads/edd folder so i moved the file over as directly and it downloaded but the original worry has arrisen. a simple click on google chrome to show all downloads, reveals that file url which is not protected in the /uploads/edd folder, one can simply copy this url and hand it out to anyone.
Make sense now?
Now it seems the only way this plugin works is a http url in the FileURL line instead of an absolute path hich i had working fine before and this new method exposes the url to someone during a download that can now be easily traded.
Ah, I see what you mean by the file path. Giving an absolute path was never intentionally supported (simply for ease of use), it just happened to work earlier. It definitely does not work with the current version, but it’s on my todo list to update because I can definitely see that being advantageous for users (such as you) who want to place their files outside of the webroot.
Can you walk me through the process of how you managed to reveal all the downloads? That is obviously not good if you were able to do that, and (at least in how it was intended) that should not be possible.
Thread Starter
hevenz
(@hevenz)
It’s pretty easy to do with google chrome, do a test payment as usual with the file you are selling and when you click the link in the email received, simply hit CTRL+J to open your download history in Chrome and viola, your download link(s) without the key encryption.
Any way to revert to absolute paths as you had enabled before?
Thanks for the help 🙂
