Thanks for your responses. I stumbled across something, however.
I'm using Jrun 2.3.3 on NT, so I'm not sure if that has anything to do
with what I have experienced.
During the shopping session, non crucial info (items etc, no credit
info) is kept in a session on the unsecure server's instance of Jrun.
When the user is ready to checkout, all info except the credit card info
is gathered and stored in the session. When the order needs to be
finalized--i.e. credit info is needed--the amount is passed in an url to
a form on the secured server. When the credit authorization is
complete, the reference number is passed back to a servlet on the
un-secured server where the session is still alive and waiting. The
reference number, along with all item and pertinent shipping info is
then committed to the database.
Is this a "dangerous" implementation? What kind of problems am I
setting myself up for, if any? At this time, there are only two
machines involved. Am I correct in thinking that the database method is
best in a "load balanced" architecture where perhaps a user might not be
sent back to the same orginating server?
Thanks for your input.
.Donnell
On Tue, 14 Nov 2000 11:24:17 CST, Sreekumar Pillai <[EMAIL PROTECTED]> wrote:
>We ran across the same issue in a previous project and this is how we solved
>it.
>
>1. Create a unique sessionID.
>String theSessionKey =
>theSession.getId() + theSession.getCreationTime();
>long value = ( long ) ( Math.random() * 100.0 );
>theSessionKey += String.valueOf( value );
>
>2. Insert the current SessionInformation (all the non-secure information to
>be passed to the secure server) in a database table with the primary key as
>"theSessionKey".
>
>3. Create a SessionManager singleton object which contains a hashtable of
>HttpSession objects. Add the current session object to the hashtable.
>
>3. Connect to the secure server and pass the session key through URL.
>(https://securesite.domain.com\servlets\paymentServletOrJSP?sessionKey=blah")
>
>4. The secure session retrieves the information from the database record and
>records user actions in the same table.
>
>5. Redirect the user to the non-secure server with the SessionKey.
>
>6. The non-secure server retrieves the information from the database and
>gets the HttpSession from the SessionManager singleton object.
>
>7. Clean up the database record with the SessionKey. You can write a
>database procedure to check the SessionInfo table for records which are
>longer than 15 minutes (session timeouts) and, if exists, delete them.
>
>If you need to carry the entire shopping cart to the secure server, you need
>to store a lot of data in the database. Another option is to carry only the
>total amount to the secure server.
>
>Sree Pillai
>
> > Date: Tue, 14 Nov 2000 11:44:48 -0500
> > Reply-To: A mailing list about Java Server Pages specification and
> > reference <[EMAIL PROTECTED]>
> > Sender: A mailing list about Java Server Pages specification and
> > reference <[EMAIL PROTECTED]>
> > From: Burr Sutter <[EMAIL PROTECTED]>
> > Subject: Re: Shopping Cart Apps/Sessions Across Multiple Servers
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > I assume both servers are under your adminstrative and programmatic control
> > so here are some ideas:
> > - Use the database to store the information and pass the secured server a
> > cookie, hidden field or URL argument with a key to the database record.
> > This trick is very popular in that "state" can persist for a few days if
> > needed. The major disadvantage is that you need a scheduled job that will
> > clean up old transactions that were never completed. One advantage to this
> > trick is that you are protected from the server going down and all the
> > in-memory stuff being lost.
> > - Use something like RMI or JMS to "push" the data to the other servers.
> > This trick has been popular for app. server vendors who give you session
> > replication or session level fail over.
> >
> > Burr
> > [EMAIL PROTECTED]
> >
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
