> Craig McClanahan wrote:
> One way to approach this would be as follows:
> * Session is established in the non-secure servlet context
> * Non-secure servlet sets a custom cookie with the session ID
> of the session in question (it will know it's own session ID without
> having to use any deprecated methods).
...SNIP ...
> * A similar approach can deal with the secure servlet wanting to
> update something -- it creates what amounts to an "upload"
> request, passing a stream of serialized Java objects that the
> non-secure servlet uses to update the session contents.
Thanks for the ideas. Let me know what you think of this idea. A few hours
after I posted the question, I found the June JDJ which describes WebLogic's
approach which is to store state information about the application in the
database.
I'm not sure of the internals of this but I got to thinking about another
possible way to handle this.
I thought that I could pass the sessionID in a cookie or URL to the secure
server. This would then be passed onto a servlet on the secure server for
processing along with the secure form data (e.g., credit card, etc.). This
servlet would process the data for validity and then write the form data and
the session id into a table on a database using the sessionID (which I
believe is unique) as primary key and then use the HttpSessionBindingEvent
and HttpSessionBindingListener classes to wait for the session to be bound
again and then that event could trigger a read of the form data table and
add it to the current session. Also it could delete the row from the
database. Is this excessive I/O for something like this?
Any thoughts?
Mike
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
