Kevin Murphy wrote:
> 1) Write secure files to MySQL as a blob (only secure files would be
> written there)
Personally I don't like this strategy but it is always a hot topic on
this list. I don't mind storing a few small images in the db but when
you start to store >200-300Megs it just complicates your database backup
strategy. If you use snapshot-based filesystem level backups (e.g. using
LVM) then this is mitigated but still has many downsides IMO.
> 3) Use Unix passwords to protect a folder in the web level and then the
> CMS knows the password and can pass the password for access (so that the
> user doesn't know this password, but the CMS does).
Nah... seems to complex.
> 4) Some various forms of link obfuscation, where the CMS goes through
> all the secure files once an hour or so and rewrites the file name with
> a random string.
Still not 100% secure and overly complex IMO.
> 2) Write secure files to the level below the web root and come up with a
> way of copying the files over to a temporary directory for access, then
> delete the files as soon as they are accessed.
> 5) Or ???? I'm open to suggestions.
I think you are kind of on the right track with 2 but there is no need
to do this copying.
Simply put all requests for your file through a PHP script. This can be
done with PATH_INFO or mod-rewrite in Apache (just google this for examples.
You PHP script will then check the access credentials of the user (e.g.
a logged in Session) and then output relevent cache headers (again
google) before issuing a Content-Type header with the correct mime type
for the file in question along with the Content-Length header with the
physical size of the file (not strictly speaking necessary but nicer for
the client) before simply calling
"include('/path/to/file/not/in/webroot.ext') to push the content to the
user.
Hope this helps.
Col
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
