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

Joel Shapiro jsfmp at earthlink.net
Thu Jul 29 11:42:43 MDT 2010


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



More information about the FX.php_List mailing list