Well if you want to be concerned with this, you could store the IP address
of the
calling user when you create the session, since that is passed to you with
their
initial http request. (note that this isnt necessarily the user's IP
address, but
it is an identifier that is unlikely to change during the course of the
user's
session).
I suppose it's theoretically possible that the rogue user spoofs this
information
as well, but it's unlikely the user will know both the user's key/ip
address/and
the fact that he currently has a live session.
Also, regardless of where you choose to keep your state, the only way of
keeping
stateful session bean handles between JSP/servlet pages I'm aware of is to
put them
into httpSession, so this problem is really inherent in both architectures.
-David
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Mr. Jake
Sent: Tuesday, June 06, 2000 10:00 AM
To: [EMAIL PROTECTED]
Subject: Re: Servlet sessions vs statefull session beans
I have another question that piggybacks on this one. Let's suppose you do
keep the state in an HttpSession, and that your app server knows how to
direct requests to get the HttpSession info regardless of what machine in a
cluster it lives on.
My question is, how do you guarantee security of that information? Suppose
that you have cookieId 222. You go into your cookies and change this
manually to 333. Suppose that the person who *really* had cookieId 333 is
currently logged on to your system, and thus their session is still
valid. This would mean that you would be able to hijack another user's
session. How do you get around this?
Thanks,
Jake
At 09:10 AM 6/6/00 -0400, you wrote:
>Most of the replies to Jim's question seemed to favor HttpSession over a
>Stateful Session Bean (SFSB). In some applications, I also agree that this
>is the best approach. In a simple environment, an HttpSession is held in
the
>memory of the web server, therefore it is very fast. In those situations
>when the HttpSession is clustered (either shared or duplicated) or
>persistent, the speed advantages decrease.
>
>Some other respondees propose keeping the state closer to the client for
>speed. This argument begins to fall apart when those clients require access
>to other resources, such as database servers, and more importantly EJB
>servers. If an HttpSession object is holding multiple references to EJB
>handles, you may want to consider a SFSB. Speed and efficiency is achieved
>when the bulk of inter-process communication is reduced. This has little to
>do with where state is maintained.
>
>jim
>
>----- Original Message -----
>From: Jim Archer <[EMAIL PROTECTED]>
> > I am interested in peoples opinions on the relative advantages and
> > disadvantages of servlett sessions and statefull session beans. I have
>read
> > many places that statefull session beans are inefficient, since they
> > instantiate a bean that lives as long as a client does, and there is one
> > per client.
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
----------------------------------------------------------------------------
------
Jake Reichert email: [EMAIL PROTECTED]
Technical Lead Phone: (415) 876-7500
Allpredict Fax: (240) 250-5593
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
