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

Dale Bengston dbengston at tds.net
Fri Jul 30 09:14:43 MDT 2010 

... with the usual cautions and caveats about using automated calls to a function that deletes stuff. 

On Jul 29, 2010, at 1:16 PM, Joel Shapiro wrote:

> Got it.
> 
> Thanks so much, Dale!
> 
> -Joel
> 
> 
> On Jul 29, 2010, at 11:13 AM, Dale Bengston wrote:
> 
>> The last time I did it, I set it up so that logins by admin-level users, who are in and out of the system every day, trigger the housekeeping. I was concerned that it might slow down logins, but it hasn't made a perceptible difference. Probably because the actual deletion of "expired" temp folders is spread out over many users, all day.
>> 
>> Crude but effective.
>> 
>> Dale
>> 
>> On Jul 29, 2010, at 12:42 PM, Joel Shapiro wrote:
>> 
>>> Thanks Leo & Dale
>>> 
>>> Dale: How are you automating your "scripts that housekeep..."?  Cron?  Something else?
>>> 
>>> -Joel
>>> 
>>> 
>>> On Jul 28, 2010, at 5:04 PM, Dale Bengston wrote:
>>> 
>>>> 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
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> 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