> Nick Neuberger wrote:
>
> Hello,
>
> I have some questions that maybe some of you die-hard servlet
> programmers can answer.
>
> HttpSession session = req.getSession(true);
>
> Do the session variables assigned to the HttpSession get sent across
> the network to the client on output?
No. The session object exists only on the server. What is sent to the
client depends upon how the servlet engine is handling session
management. Currently there are two methods; firstly a cookie is sent to
the browser with a session key in it, this is then requested from the
browser when getSession is called, and used to establish some kind of
session state (http being fundamentally stateless). The second is to
embed a similar session key in rewritten URLs; in order to do this there
are output filters that you have to pass any URLs you emit from servlets
through which should rewrite them correctly. Take a look at Sun's
website for an example of URL rewrites and what they look like.
> This brings up some major questions if they do or do not. A friend of
> mine told me how ASP pages send the session object. ASP will
> generally send a GUID (Global Unique ID) back to the client for later
> reference. This eliminates sending a vital information in the session
> vars.
>
> Advantages to sending the session object across the network:
> 1) Completely disconnected. If in a clustered environment, the
> session always goes to the received server. This is a known problem
> in ASP/IIS Clusters. "Loosing session state".
Bear in mind that often your session object contains resources such as
database connections and references to other external objects. Even if
the session object were in some way sent across the network to the
client, it still wouldn't be independent of the network. In addition,
I'm currently working with a system that leaves a reference to a (very
large) remote object in the session. If it had to send that object
across the network every time someone asked for a session then it would
rule out anyone on a slow (<100Mbs) connection :)
> 2) All key information is sent across the network. Viable
> information, such as credit card information. Is it lightly encrypted
> or is it just plain text.
Remember that if you're using servlets to store credit card information,
it's presumably got to be sent over the network at some point. It won't
as part of the session object, but there's still that security concern
there.
> Disadvantages/Advantages to keeping the session object at the server:
> 1) No vital session variables will go across the network. Security
> isn't compromised.
Well, strictly speaking someone could snoop on your network connection,
grab the session key and spoof it, but it's unlikely :)
> 2) Session problems with clustering if a guid is passed and stored on
> the server.
You're using java. If you want clustering with servlets, then have one
machine handling the requests and passing them onto the others if you
need more power. This allows the gatekeeper machine to handle the
session tracking and is all happy. The 'one to many' dns based
clustering is (IMHO) an absolutely hideous way of doing clustering
anyway.
> Does anyone have any feedback on this? Any information would be
> great!!!! My primary worry is security.
Well, servlets are the way to go wrt security anyway.
> Go Servlets!!!! Go RAMS!!!!
Indeed.
Tom Oinn
(Programmer, swissprot group, European Bioinformatics Inst.)
--
We opened up Pandora's box, just to see if she was home
She had an apple pie, a jaundiced eye and a big red telephone..
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
