[FX.php List] [OFF] Restricting web directory/downloads via FM?

Andrew Denman adenman at tmea.org
Fri Jul 30 10:52:31 MDT 2010 

I currently use a readfile() style of pass-through after authenticating users for downloaded files, but will probably be moving to the temp folder style in the near future.  The files are large audio files and can bog down the server since everything runs through PHP and now a CMS. The CMS is the killer in my case because it buffers the output; scripts were growing to 256MB+ memory usage.  Just an FYI for those who have large files.

Andrew Denman

-----Original Message-----
From: fx.php_list-bounces at mail.iviking.org [mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Dale Bengston
Sent: Wednesday, July 28, 2010 7:04 PM
To: FX.php Discussion List
Subject: Re: [FX.php List] [OFF] Restricting web directory/downloads via FM?

I handle this by storing the assets in one place and copying them to another area for download. Within my user download folder, I create a temp folder (named the timestamp in milliseconds) and copy the asset there. (I can also rename it, or further process the copy in the new location.) Then I initiate the user's download from the temp folder.

I have automated scripts that housekeep the timestamp temp download folders so they disappear pretty quickly. This keeps the files from piling up, and ensures that if someone's trying to hack my folder structure and see what else is available for download, they won't get anything unless they happen to put a folder name in with the exact number of milliseconds of another download, plus know the file name.

Works great.

Dale


On Jul 28, 2010, at 6:03 PM, Kevin Futter wrote:

> Thanks Leo. We do all our online authentication via AD and LDAP, so 
> it's just a matter of writing that into a session. We're looking at 
> providing online access for parents to their sons' school reports, but 
> it's obviously crucial that they can't access anyone else's, and vice versa!
> 
> Not sure when I'll get time to look at this, but I have a few more 
> months until the next reporting period.
> 
> Kev
> 
> On 29/07/10 8:57 AM, "Leo R. Lundgren" <leo at finalresort.org> wrote:
> 
>> Sure, no problem! I suggest you start by making a basic solution like 
>> the one described with a script that 1) takes a username and password 
>> and checks the database, 2) readfile()'s the file if the authentication is successful.
>> 
>> Either you could make the script get all three parameters (username, 
>> password,
>> filename) in one go (the client would have to make the link include 
>> the parameters in the URL), or you could make the script first 
>> present a login box and then do the above when the user submits the form on it.
>> 
>> 
>> 29 jul 2010 kl. 00.49 skrev Kevin Futter:
>> 
>>> I have a forthcoming need to do something similar to this too, so I 
>>> appreciate your response here Leo. Any additional info would also be 
>>> appreciated!
>>> 
>>> Kev
>>> 
>>> On 29/07/10 8:20 AM, "Leo R. Lundgren" <leo at finalresort.org> wrote:
>>> 
>>>> Did you Google any of this? There's a ton of information out there 
>>>> on this essential functionality.
>>>> 
>>>> There are many ways to do it. First of all you need the 
>>>> authentication, which you can do upon request, firing a query to 
>>>> the database, or by caching information so you don't need a trip to 
>>>> the database for each request.
>>>> 
>>>> Then you need a way to protect the files. The obvious solution is 
>>>> to have them placed in a directory that is not directly accessible 
>>>> from the web (for example by having a "deny from all" in Apache's 
>>>> rules, which could be in a .htaccess, or some equivalent measure in 
>>>> other web servers).
>>>> 
>>>> Then to bind this together you could write a script that processes 
>>>> the request and readfile()'s the requested file if it exists and 
>>>> the user provided valid credentials. If the files are big 
>>>> readfile() might not be that fun to use since it literally relays 
>>>> the entire file using PHP, but there are other ways to do it in 
>>>> that case. One example is to make the web server protect the files 
>>>> by asking your PHP script for authentication, and if the auth 
>>>> succeeds the web server sends the file instead of PHP, which is 
>>>> more effective.
>>>> 
>>>> The readfile() method probably works as a start though, depending 
>>>> on your file sizes and the number of requests you'll get. As you 
>>>> say its PDF files I suppose they won't be that huge :)
>>>> 
>>>> -|
>>>> 
>>>> 29 jul 2010 kl. 00.03 skrev Joel Shapiro:
>>>> 
>>>>> Hi all
>>>>> 
>>>>> I've got a new client that would like to make some downloadable 
>>>>> materials (mostly PDFs) available to their authorized users.  The 
>>>>> client would like to be able to upload files to some directory on 
>>>>> their site and have only logged-in users (authenticated via FMP 
>>>>> "users" table) be able to view and/or download them.
>>>>> 
>>>>> Anybody have any thoughts on the best & simplest way to do this?  
>>>>> (or are best and simplest mutually exclusive? ;)
>>>>> 
>>>>> I've thought of giving the client access to edit an html page with 
>>>>> links to each of the downloadable files -- and I'd make that page 
>>>>> accessible only to logged in users.  Are there easy ways to avoid 
>>>>> having the client have to update html and hrefs?
>>>> 
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>> 
>>> 
>>> --
>>> Kevin Futter
>>> Webmaster, St. Bernard's College
>>> http://www.sbc.vic.edu.au/
>>> 
>>> This e-mail and any attachments may be confidential. You must not 
>>> disclose or use the information in this e-mail if you are not the 
>>> intended recipient. If you have received this e-mail in error, 
>>> please notify us immediately and delete the e-mail and all copies. 
>>> The College does not guarantee that this e-mail is virus or error 
>>> free. The attached files are provided and may only be used on the 
>>> basis that the user assumes all responsibility for any loss, damage 
>>> or consequence resulting directly or indirectly from the use of the 
>>> attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College.
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>> 
>> 
>> 
>> -|
>> 
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
> 
> --
> Kevin Futter
> Webmaster, St. Bernard's College
> http://www.sbc.vic.edu.au/
> 
> This e-mail and any attachments may be confidential. You must not disclose or use the information in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. The College does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. The content and opinions in this e-mail are not necessarily those of the College.
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list

_______________________________________________
FX.php_List mailing list
FX.php_List at mail.iviking.org
http://www.iviking.org/mailman/listinfo/fx.php_list

More information about the FX.php_List mailing list