how to secure documents in server

[RAZZ]

Hello, Can anyone suggest me solution?

I Need to manage different types of documents (doc,xls,ppt etc) in
server. I have folder structure to maintain these documents in server.

Say folder1 is having all doc files; folder2 is having all xls files
and so on.
Now these documents should not be able to get access through the url
by directly typing path.
E-g if I try to access directly www.mywebsite.com/folder1/xyz.doc it
will open the document in browser itself.
At the same time these documents should be access only through our
website once they are login. But without login also if you know the
path you can get these documents how should I avoid it?

How can I provide security to these documents in server?

[Bart Van der Donck]

Captain Paralytic wrote:

Actually another way to do it is to store the files in a BLOB field in
a database and delivering them from there. Here is a tutorial for that
and you could adapt it for the file system version:
http://www.php-mysql-tutorial.com/php-mysql-upload.php

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database. Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

--
Bart

[Pugi!]

I do not know the details of your provider or host but if you can
store your documents outside of your documentroot, no one can access
your files directly. You can use php to store them and retrieve them.
I store the filename and mimetype in database (and some other
information), files are stored in a directory outside documentroot
where apache has read/write access (because users are allowed to
upload documents) (in my case the documents are even stored on another
server with NFS share). Once you obtained the filename and mimetype
from database and path from config file:

header("Cache-Control: max-age=60");
header('Content-type: ' . $filemime);
header("Content-Disposition: attachment; filename=\"" . $filename .
"\"");
readfile($filep ath . $filename);

It not only downloads the file but also asks if you want to open it
with the associated program (MS Word or OO Writer for *.doc, ...)

Pugi!

On 18 jul, 12:05, RAZZ <rajat82.gu...@ gmail.comwrote:

Hello, Can anyone suggest me solution?

I Need to manage different types of documents (doc,xls,ppt etc) in
server. I have folder structure to maintain these documents in server.

Say folder1 is having all doc files; folder2 is having all xls files
and so on.

Now these documents should not be able to get access through the url
by directly typing path.
E-g if I try to access directlywww.myw ebsite.com/folder1/xyz.docit
will open the document in browser itself.
At the same time these documents should be access only through our
website once they are login. But without login also if you know the
path you can get these documents how should I avoid it?

How can I provide security to these documents in server?

[J.O. Aho]

RAZZ wrote:

Hello, Can anyone suggest me solution?

There been those who already mentioned to store the files outside the web
servers "document root", this is the most secure method (of course depending
on the security of the script/application that supplies the file, in worst
case this can endanger the security of the whole server).

..htaccess and similar web server restrictions has the draw back that not
everyone offers this and it can be easy to do it the wrong way when
unexperienced with web server configuration.

The idea of storing binary files in a database is quite good, but it will
affect the sql server in a negative way, specially the larger the binary files
are.

A fourth method is to encrypt the files and store them in the "document root",
and the special download script decodes the file when downloaded by someone
with access to get the decrypted file. (this can be combined with all the
other methods too), this way someone accessing the file directly can't use it.

A lot simpler way is to rename the files to something quite random (md5 hash
the name, don't forget to salt it), store the hashed filename in a database
table where you have the original filename too. The download script in this
case will take an argument of the original filename, look in the database for
the hashed name, provides the file to the user (with header you send it as the
original name), this way you can't get the file with direct download unless
you know the hashed file name. If you combine this one with the previous
method, you should have a quite good false security on the files.

--

//Aho

[The Natural Philosopher]

J.O. Aho wrote:

>
The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger the
binary files are.

Ok, why should it take longer to pull a large file out of one locatin in
a database than one location in a filesssytem?

IME the things that slow databases down are not getting data out of
them, its performing complex relational queries.

[Paul Lautman]

Bart Van der Donck wrote:

Captain Paralytic wrote:

>Actually another way to do it is to store the files in a BLOB field
in a database and delivering them from there. Here is a tutorial for
that and you could adapt it for the file system version:
http://www.php-mysql-tutorial.com/php-mysql-upload.php

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database.

It doesn't because it isn't

Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

I usually chunk the files into BLOBs

[Paul Lautman]

The Natural Philosopher wrote:

J.O. Aho wrote:

>>
The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger
the binary files are.

Ok, why should it take longer to pull a large file out of one locatin
in a database than one location in a filesssytem?

IME the things that slow databases down are not getting data out of
them, its performing complex relational queries.

I have tested this and I have found it slightly slower to get files from a
database table than from the file system. Then again, it is slightly slower
building pages dynamically with php/MySQL than it is to serve fixed html
pages. So basically, when I find that storing files in a database is the
best way to handle the application I am writing, that's the way I do it.

[Jerry Stuckle]

Bart Van der Donck wrote:

Captain Paralytic wrote:

>Actually another way to do it is to store the files in a BLOB field in
a database and delivering them from there. Here is a tutorial for that
and you could adapt it for the file system version:
http://www.php-mysql-tutorial.com/php-mysql-upload.php

I'm surprised this document doesn't mention how disastrous it can be
for the performance of a database. Only use for tiny binary data and a
limited amount of records, I'ld say... I would even vote to dismiss
LONGBLOB; it often creates more problems than it solves.

--
Bart

You're just using the database for what it's made for - storing and
accessing data. It's not at all disastrous - in fact, if you get enough
files in the database, performance may actually improve over that file
system's.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jerry Stuckle]

J.O. Aho wrote:

RAZZ wrote:

>Hello, Can anyone suggest me solution?

There been those who already mentioned to store the files outside the
web servers "document root", this is the most secure method (of course
depending on the security of the script/application that supplies the
file, in worst case this can endanger the security of the whole server).

.htaccess and similar web server restrictions has the draw back that not
everyone offers this and it can be easy to do it the wrong way when
unexperienced with web server configuration.

The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger the
binary files are.

A common misconception by those who haven't used databases for storing
large amounts of data. Properly configured, the database will have
excellent performance.

A fourth method is to encrypt the files and store them in the "document
root", and the special download script decodes the file when downloaded
by someone with access to get the decrypted file. (this can be combined
with all the other methods too), this way someone accessing the file
directly can't use it.

A lot simpler way is to rename the files to something quite random (md5
hash the name, don't forget to salt it), store the hashed filename in a
database table where you have the original filename too. The download
script in this case will take an argument of the original filename, look
in the database for the hashed name, provides the file to the user (with
header you send it as the original name), this way you can't get the
file with direct download unless you know the hashed file name. If you
combine this one with the previous method, you should have a quite good
false security on the files.

Even worse performance than storing the data in the database in the
first place. More overhead for the scripting language, while no
significant savings on the database end.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jorge]

On Jul 18, 8:58*pm, The Natural Philosopher <[e-mail] e:

J.O. Aho wrote:

The idea of storing binary files in a database is quite good, but it
will affect the sql server in a negative way, specially the larger the
binary files are.

Ok, why should it take longer to pull a large file out of one locatin in
a database than one location in a filesssytem?

I think the point is that retrieving such a large data chunk from a db
might momentarily impact the performance of forthcoming db operations,
think about what happens to the sql database caches.

--Jorge.

[Joost Diepenmaat]

Jerry Stuckle <js*******@attg lobal.netwrites :

But try putting 100K files in a directory on the file system and see
how much it slows things down. Whereas the database will hardly
notice any performance decrease.

That really depends on the filesystem. But yeah, most common file
systems don't like that. In any case, neither relational databases nor
normal file systems are optimized for this kind of use - especially
not if the blobs are large.

In other words, your mileage may vary. See also
http://perspectives.mvdirona.com/200...sOfPhotos.aspx

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/