First of all Thank you very much for all useful responses from Matt, Jeff, Ronnie and Michael.
Coming to my response for all the mail. Divine Content Server is J2EE complaint and its highly scalable and it does provide all the security model. We serve all images, document through it blobsever mechanism (Its a servlet). And we can also cache all the documents so its pretty good content delivery model and there is no complaint about that. But the requirement which I posted is a special requirement that I need to come up with a pretty small internal site for very limited audience. We have around 200 PDF's which size varies from 12MB to 25MB which Divine Content Server handles But each of them got a different username and password and the Document size might increase to 40MB(PPT). So I do not want to server 40MB document through APP server. So I have the content managed website on hand through I can either serve the document through blobsever(Lets say APP server) or through file system. When I serve Documents through blob we have two options 1. Blob Security OFF (Any one can download the document if you have the URL) 2. Blob Security turned ON( NO one can see the document unless you log in). Cool that's what I am looking for. But each of our website got some "special requirement" that made us to Turn OFF the blob security. We developed more than 25 sites with different requirement. So JUST FOR THIS PRETTY SMALL site I do not want to screw the existing security setting. In other way, even though I keep the documents on Content Server I pull the document through a cron job and post it to the web server and just deliver through file system. I would like to stick with this option(serve through fie system) Matts first suggestion seems pretty good - Site is a content site, and when the user select the download basic authentication should handle the request and serve the documents from the file system. Here first I need to authenticate the user and serve his personalized content and when the user is about to down load again he needs to enter the username and password. So the username in Content Server needs to be mapped to LDAP for basic authentication too. Double work but this model is secure. Matts second suggestion looks like what Content Server blob mechanism does, I would like to keep it as the last option. Ronnie solution seems good, I can use a JSP to server the documents as you suggested. Coming to Michael Doesn't the 'username/password' already block 'other users'? What's the username/password for if not for blocking unauthorized access? - Yes it blocks, but when you download the document smart user can see the URL lets say www.localhost.com/doc/test.pdf and any one can download if the user forward the document URL. Here I would like to add Ronnie solution by serving through a JSP code. Still in a dilemma in selecting the above said options! Any suggestion to selecting the right above discussed model would be appreciated or if any one point out the flaws in any one of the solution is also fine. Again thank you very much for all the responses, Chandran... --- michael kimsal <[EMAIL PROTECTED]> wrote: > On Thu, 2003-01-16 at 16:52, Chandran P wrote: > > Thank you very much for the reply Darrel & Matt. This site is to be > > developed using Divine Content Server with iPlanet. Divine provides a > > secure way of delivering content(blobs) to the user. But I was > looking > > different solutions to serve the documents serving through file > system > > and NOT through app server. We have PDFs with 12MB and I do not want > to > > server through app server since it reduce the performance. On top I > could > > try by encryption and decryption but there should be some other > simple > > way to do this. > > > > Hello Chandran: > > you said: > ---------- > I have a website with 100 PDFs each with different user name and > password. The user can enter the corresponding username and password > and > can view the corresponding pdf. Its been served from the file server. > <www.host/document/test.pdf> > > Question here is security. I would like to block other users to > access > the document. > --------- > > Doesn't the 'username/password' already block 'other users'? What's > the > username/password for if not for blocking unauthorized access? > > Generally an app server is supposed to take care of this stuff - > they're > used to make these kinds of gyrations easier. If your current app > server is that much of a bottleneck in terms of serving up these files > with appropriate security measures in place, you should consider a > migration to something more robust. I suspect divine can handle what > you're trying to do fine, but perhaps not - testing is the only way to > determine for certain in your current set up. > > > -- > Michael Kimsal > http://www.logicreate.com > http://www.phpappserver.com > 734-480-9961 > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- http://cms-list.org/ more signal, less noise.
