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?

[Jerry Stuckle]

Bart Van der Donck wrote:

The Natural Philosopher wrote:

>Bart Van der Donck wrote:

>>(1) Read actions without BLOB:
- Application does not load any BLOB data from database.
- Application uses a var holding the system-path (usr/my/path/to/
pics/), adds the ID to it, adds .jpg to it, tests if file exists (-e).
- If yes, use URL-path in stead of system-path and output inside an
<IMGto screen.
- No binary data has to be handled; the major memory use here (if any)
is the -e check for file existance. But even this could be skipped
with a workaround.
(2) Read actions with BLOB:
- Load BLOB from column (already a memory-intensive task of its own).
- Store in some folder (id.).

>>It is my experience that (1) has huge memory benefits compared to
(2).

The way I do it, it streams off the database via the unix socket into
PHP memory space, and is outputted from there via the web server to the
network.

VERY little extra PHP or CPU activity is required, but I grant you its
probably held in PHP and SQL type memory areas as well as disk cache
memory. Its probably NOT held i e.g.apache memory though..apache or
whatever will read the stdout of the CGI script that spits it, and juts
pass the bytes...and memory is cheap. Cheaper than CPU anyway.

All I do is this:

SELECT id FROM table;
print "<img src=url/to/$id.jpg>";

Compared to your way:
- Simpler
- No need to start new php scripts to output raw binary stream for
every image
- No sockets
- No need to read heavy binary BLOB from DB
- No chance for possible cache attacks in MySQL, PHP, filesystem or
Apache

I don't want to sound religious, but I think my way is much better.

--
Bart

It's easier for YOU. And you THINK your way is better. But you've
never really tried with lots of images, have you? In fact, I suspect
you've never really checked it at all with a real database which has
been designed and configured to do this type of operation.

So all you really have to go on is your opinion.

OTOH, some of us have been doing it for years (over 20, in my case,
starting with DB2 on mainframes), and have both designed databases and
configured RDBMS's to handle these operations efficiently. We've seen
the difference in performance, and it isn't what you claim.

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

[Bart Van der Donck]

Jerry Stuckle wrote:

Bart Van der Donck wrote:

>* *SELECT id FROM table;
* *print "<img src=url/to/$id.jpg>";

It's easier for YOU. *And you THINK your way is better. *But you've
never really tried with lots of images, have you? *

Yes I have, and the tests with BLOBs were disastrous for my case
(although I must admit this study was done already 9 years ago).

Perhaps you're right that my requirements were a bit particular; I'm
facing a read load of a few MB/sec and a modest update/delete load
only peaking at nightly cronjobs. Images are spread on the machine
over 57 directories, the largest directory is holding 22,241 images at
this moment. Maybe it's BSD or the running shell that is optimal (?);
one thing I know -and tested well enough- is that my MySQL cannot
handle this kind of BLOB "abuse" under such conditions.

I can understand it might be desirable that the URL to the image must
be unknown, like Natural Philosopher said, or other requirements which
make this or that approach more preferable. In my case the binaries
are about hotel photos having their telephone number as the name of
the JPG's. This level of protection is acceptable here; performance
critera are more crucial.

In fact, I suspect you've never really checked it at all with
a real database which has been designed and configured to do
this type of operation.
So all you really have to go on is your opinion.

It's unwise to draw a conclusion from something you only suspect.

But you're right, it's my opinion, but based on experience and
proceeded by quite some study and benchmarks. I think that, for my
case, it was the best possible design under the given requirements.

--
Bart

[Jerry Stuckle]

Jones wrote:

On Mon, 21 Jul 2008 06:46:33 -0400, Jerry Stuckle <js*******@attg lobal.net>
wrote:

>Not necessarily. Sysadmins cannot correctly set up a system in the
dark. They need communications from the developers on what data is
being stored, how it is being handled, etc.

Once upon a time the term, "system analyst" actually meant something.
And then Alan Sugar started selling desktop PC's to everyone and now
everyone thinks they're a "software engineer" just because they can hack
a few lines of PHP or type ./configure.

The "developers " should have worked it all out before the project even started.
Thats the REAL problem - here presumably and elsewhere for certain.

No, there are still sysadmins, who are responsible for system tuning.
It isn't just the needs of the database developers which needs to be
taken into consideration - there are others, also.

Of course, you're right - nowadays there are too many "system
administrators" who only hold that title because they failed Programming
101.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jerry Stuckle]

Bart Van der Donck wrote:

Jerry Stuckle wrote:

>Bart Van der Donck wrote:

>> SELECT id FROM table;
print "<img src=url/to/$id.jpg>";

It's easier for YOU. And you THINK your way is better. But you've
never really tried with lots of images, have you?

Yes I have, and the tests with BLOBs were disastrous for my case
(although I must admit this study was done already 9 years ago).

How many is a lot? I've done it with over 50M images (several terabytes
- but that was a mainframe) in a database with no performance
degradation. But the database and RDBMS were designed to do it, also.

And this was under live conditions, averaging 10K queries/second.

Perhaps you're right that my requirements were a bit particular; I'm
facing a read load of a few MB/sec and a modest update/delete load
only peaking at nightly cronjobs. Images are spread on the machine
over 57 directories, the largest directory is holding 22,241 images at
this moment. Maybe it's BSD or the running shell that is optimal (?);
one thing I know -and tested well enough- is that my MySQL cannot
handle this kind of BLOB "abuse" under such conditions.

Do it all in one directory. That's what the database effectively does.
And it means you don't need to sort images into different directories,
create new directories when the images get too large...

I can understand it might be desirable that the URL to the image must
be unknown, like Natural Philosopher said, or other requirements which
make this or that approach more preferable. In my case the binaries
are about hotel photos having their telephone number as the name of
the JPG's. This level of protection is acceptable here; performance
critera are more crucial.

>In fact, I suspect you've never really checked it at all with
a real database which has been designed and configured to do
this type of operation.
So all you really have to go on is your opinion.

It's unwise to draw a conclusion from something you only suspect.

But you're right, it's my opinion, but based on experience and
proceeded by quite some study and benchmarks. I think that, for my
case, it was the best possible design under the given requirements.

--
Bart

Yep, but your "study" and "benchmarks " were not necessarily accurate.
So neither are your conclusions.

Tune the RDBMS and design the database correctly, and there is virtually
no overhead. After all, all a file system is is a dumb dbms.

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

[Geoff Berrow]

Message-ID: <g6**********@r egistered.motza rella.orgfrom Jerry Stuckle
contained the following:

After all, all a file system is is a dumb dbms.

Don't you mean, a file system is a database?

--
Geoff Berrow 011000100110110 0010000000110
001101101011011 001000110111101 100111001011
100110001101101 111001011100111 010101101011
http://slipperyhill.co.uk

[Jerry Stuckle]

Geoff Berrow wrote:

Message-ID: <g6**********@r egistered.motza rella.orgfrom Jerry Stuckle
contained the following:

>After all, all a file system is is a dumb dbms.

Don't you mean, a file system is a database?

No, the files are a database. A file system is a dump database
management system.

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

[Jerry Stuckle]

Jerry Stuckle wrote:

Geoff Berrow wrote:

>Message-ID: <g6**********@r egistered.motza rella.orgfrom Jerry Stuckle
contained the following:

>>After all, all a file system is is a dumb dbms.

Don't you mean, a file system is a database?

No, the files are a database. A file system is a dump database
management system.

Whoops - mistype. That should be "A file system is a dumB database
management system". But come to think of it, it is kind of a dump, also :-)

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