Re: Advice on dynamic graphics with WO
Re: Advice on dynamic graphics with WO
- Subject: Re: Advice on dynamic graphics with WO
- From: Jonathan Rochkind <email@hidden>
- Date: Sat, 3 Jan 2004 16:53:04 -0600
At 1:24 PM +0000 1/2/04, Jonathan Fleming wrote:
From: Michael Halliday <email@hidden>
To: Michael Engelhart <email@hidden>
How then do you put photo's into the filesystem and secure them so
that they can not be downloaded? Even if you have a login system in
effect, once the url to the image is known it can be downloaded.
Anyhow since i have never really tried the next appraoch i wonder
how effective it is if at all....
If you need to secure/authenticate access to your images.... there
might be some way to do it while still serving through the web
server, but if it were me, I wouldn't try. However. Just because you
are not serving them up simply by placing them in a directory the web
server knows about does NOT mean your alternative is storing them in
the database.
Here's what I would do: Store them in the file system. NOT in a
directory under the web server document root, but just somewhere else
in the file system, somewhere that is not exposed by any existing
network software perhaps. The WO app can, when presented with a
request for a particular resource (you might want to use direct
actions here), identify whether the user is authenticated to access
this resource, and if so, simply construct and return a WOResponse
with the proper mime type headers and content. I would use the
streaming features added in 5.2 to stream the data to the client,
rather than reading all the data into your WO apps memory at once and
returning it en toto.
Hope this helps,
--Jonathan
Storing images in the database, both thumbnail and full size images,
are they safer in the database... to me it would seem so, but then
you come up against this problem of serving up the images and
caching them. The caching is particulary important in an online
photo library because of the many hundreds of images that may be
rendered on several bached pages that a user may need to go back
over.
So generally what I am asking here is does anyone know the best
approch to keeping images secure using either the file sever system
of the database storage system.
The database I use is MSSQLServer2000 on a Windows Advanced Server
using IIS (yes, i know I've heard all the yuk, yuk stories about
IIS, but that's the way it has to be for now until my competence
level has sufficed to allow the run of a Unix based system).
Any feedback on this would be greatly appreciated.
Kind regards
...and Happy New Year to all
Jonathan :^)
I have to say that we have had no performance issues, and to me
this is the most elegant, scalable solution for several reasons:
(1) You have all of the database clustering options available to
you for data redundancy & data backup.
(2) If your site was to grow substantially in size and you
required multiple HTTP Servers (along with your multiple
application servers), if your images were served by apache from the
local filesystem you would run into issues with having to somehow
replicate your image directories across the multiple Apache
servers. I'm not saying this couldn't be done...it would just
require the proper planning. Using the database for an image store
would solve all of these issues.
(3) Using the database method, WebObjects would cache your images
so you wouldn't actually have to go to the database each time.
(4) If you need to "associate" images with other objects I'd hate
my images to be stored in the file system. You would eventually
most likely run into broken links etc...this would get rather
messy. Plus if you need to control access to images (I.E. Only
logged on users can view product images) you would need to rely on
filesystem/apache security which adds yet another layer of
complexity to your application.
Again, I know many people will probably disagree with this
approach. But, it is working perfectly for us and for dynamic
images (or images that the user can change/upload) I think it's the
most effective approach. That being said, we do use apache to
serve up our static images.
I'd be interested to hear from others and there experiences with
storing images in databases. You hear a lot of people saying
"Don't do it, it won't perform well."...but have these people
actually tried it? Or have they just been told not to do it. I
have been very interested in this topic for a while now and I have
done extensive searching but never come up with any "correct"
answer. I think it also depends on which database you use and how
exactly the database itself stores images. I know that some are
much better than others and personally this is where you'd most
likely run into the performance hit (if any).
Michael.
PS -- Happy New Year!!!
PPS -- I'm working on New Years Eve...how sad is that?!
On 31-Dec-03, at 8:25 PM, Michael Engelhart wrote:
On Dec 31, 2003, at 7:46 PM, Robert Walker wrote:
It's probable that many on this list will disagree with me on this
issue, but I have had good success, for my purposes, with this design
pattern.
I'm curious if this is in a very high traffic site or not? I
can't imagine that pulling image data out of database for every
page view is going to scale. That's my underlying reason for
saying it's a bad idea. But then again I could be wrong. :-)
I'm also curious as to whether or not a caching proxy server (say
Squid for example) can cache a copy of an image that isn't file
based? This may or may not be an issue though depending on the
application.
Mike
_________________________________________________________________
Use MSN Messenger to send music and pics to your friends
http://www.msn.co.uk/messenger
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.