>>>>> "Steven" == Steven D Meacham <[EMAIL PROTECTED]> writes:
>> -----Original Message-----
>> From: David M. Karr [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, June 05, 2000 4:16 PM
>> To: [EMAIL PROTECTED]
>> Cc: [EMAIL PROTECTED]
>> Subject: Re: regarding web security..
>>
>>
>> >>>>> "Steven" == Steven D Meacham <[EMAIL PROTECTED]> writes:
Steven> There are a couple of solutions to this. The first
>> one is for you to use
Steven> the session object, setting a value in your login
>> servlet that all the rest
Steven> of the pages look for before displaying their
>> content. This is the
Steven> servlet-way of doing it and you'll find support on
>> this list and in the
Steven> archives.
>>
Steven> Second, is to use a 3rd party single-sign-on
>> product. I don't know of any
Steven> that work with Jigsaw, so you'd probably have to
>> switch to Netscape or
Steven> Microsoft's web servers. In this case, you'd
>> probably eliminate your login
Steven> servlet and set up your security in the 3rd party
>> product's own proprietary
Steven> fashion. This is usually very secure because I
>> understand that these
Steven> products run as server plug-ins, intercepting every
>> HTTP request and
Steven> authenticating/authorizing. You'd have to go
>> elsewhere for support on this
Steven> approach.
>>
>> I see lots of value with the first option. However, is there anything
>> useful we can do to protect a page that is generated by another tool
>> (InstallAnywhere, for instance)? I can certainly have a servlet check
>> the Session object, and not redirect to the generated page if not
>> valid, but the page they get redirected to is then bookmarkable.
Steven> Now, I haven't done this one, but in the spirit of brainstorming, perhaps
Steven> doing some servlet chaining to check for a valid session
Steven> (authenticated/authorized) before passing on to the other tool like
Steven> InstallAnywhere would do the trick.
The problem is, it isn't being passed to a "tool", but just to a web
page (along with files in subdirectories) that was previously
generated in a build process by the InstallAnywhere tool. I can chain
all I want until I redirect to the InstallAnywhere root page, but once
I get there, I'm on a raw html page, which was not generated by a
servlet.
The only solution I've seen for this sort of thing is to have the
servlet copy the web page and its associated files from a directory
outside of the web server root, into a directory in the web server,
using a randomized directory name. The ugly part is knowing when to
get rid of the randomized directory name after they've finished
downloading the application.
--
===============================================================================
David M. Karr ; [EMAIL PROTECTED] ; w:(425)487-8312 ; TCSI & Best Consulting
Software Engineer ; Unix/Java/C++/X ; BrainBench CJP (4/20/1999)
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
