Summary: password protect uploads
Created: 2004-10-21 14:18
Status: Closed - fixed for 2.0.beta31
Description: It would be nice if access to uploaded files could be protected via PmWiki's passwording system instead of requiring separate .htaccess files or security setups.
Important topic at least for me. I guess there is no cookbook entry on protecting uploads yet, or did I miss it? Henning November 11, 2004, at 04:37 AM
It would help me understand this request if a proposed protection mechanism were described. Do you want to keep people from uploading unless they have a password? That exists. Do you want them to be unable to download files without a password? Would that be for selected files or files in one group or some other criteria? Does it matter if users can see the file list (are the names to be protected)? Why not encrypt the files before uploading and give authorized users the key? Then you don't need passwords at all. NeilHerber January 24, 2005, at 01:36 PM
I would like to have password-protection for files to work just like standard password-protection for Wiki pages.
The current situation makes a difference between pages and files:
If the file content is protected, the file names could be public in my opinion, though I've got to admit I haven't really thought about the security implications of that aspect.
My wish would be "protection per group", though I guess that if it's implemented at all, it will probably be desirable to have it working in exactly the same way as page protection in order to maintain PmWiki's consistency.
Since my installation handles a great number of files mostly uploaded by "naive" authors, encryption isn't really a practicable substitute for protection.
(These are just my personal ideas, of course - maybe there are different ways to make it work, or different requirements I haven't thought of yet.)
--Henning January 25, 2005, at 08:09 AM
Cookbook/UserAuth can handle protection of who can upload or change files. Check out the documentation for how to do it. But protecting files from downloading would probably require changes to PmWiki itself -- JamesMcDuffie
Are you people talking about having PmWiki change the .htaccess files? Cos this would be the only way I see for actually protecting the files. Otherwise, on the server, the uploads dir is (at least) chmod 770, so the only current protection is obscurity (pretty good for my purposes) -Radu
No, the plan is that the uploads/ directory would be either (1) moved out of the web-accessible hierarchy altogether or (2) given an .htaccess containing a "Deny from all" directive. Then any requests for attachments would be routed through the PmWiki script itself, which would check authorization credentials and supply the file as a result.
I've love to see this feature. How about leaving the documents inside the wiki.d folder? Then serving them when a request comes to pmwiki.php?n=Main.document_pdf - (where document_pdf --> document.pdf within the group Main)? Detecting the downloadable documents using the $UploadExts array...Just a thought
Hm, I'd like to retain a complex folder structure, storing them all in wiki.d sounds like it could be a bit confusing in practice.
(By the way, Rob, don't forget to add your vote for "priority" at the top of this page :-)
--Henning March 11, 2005, at 11:37 AM
The ability to password-protect uploads is now available in 2.0.beta31, however we probably still need a Cookbook recipe that describes how to do it in detail. The core of the magic is to set
...and protect the upoad/ directory from public access by moving it out of the html/ or public_html/ directory tree, or using .htaccess. --HansB
No, Cookbook/Authenticated Attach does not protect the upload / directory, so anyone knowing (or guessing) the upload directory location can download the attach files from there. --HansB
First the user blocks http access to the upload directory. (By making it private). Then you can use Cookbook/AuthenticatedAttach to allow the user to access the files in the upload directory. Invalid permissions return an empty 0 byte file. --MarkS
I'm guessing that Cookbook.AuthenticatedAttach may have been obsoleted by beta31, and that using $EnableDirectDownloads=0; is the preferred mechanism. --Pm