[FX.php List] [OFF] Restricting web directory/downloads via FM?
Joel Shapiro
jsfmp at earthlink.net
Thu Jul 29 12:16:55 MDT 2010
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
More information about the FX.php_List
mailing list