Win a copy of Practical SVG this week in the HTML/CSS/JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Client/Server Session Tracking - How?

 
jack catler
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am as new newbie as you can get - so go easy please.... ;-)
Great site I should mention!

I want to store specific users objects/beans (like shopping basket) per user session, and then retrieve them on following requests to manipulate further, query etc - standard stuff ....

Will the server remember the session for the actual user? Is there something passed (behind the scenes) to handle this? If not, what other options are there to handle this. I really don't like the idea of passing a user "sessionId" as per the JSF faces book (page 53 I believe).

As an aside, a while back I developed a similiar application using JSP/servlet and remember that this was taken care of without any special code - aside from getting/setting the object from the session.


Thanks!
Jack.
[ January 04, 2006: Message edited by: jack catler ]
 
Varun Khanna
Ranch Hand
Posts: 1400
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can create a managed bean in session scope. JSF will help you in maintaining this object in session. Behind the scene it uses HttpSession object only to store this object.
Alternatively, you can keep your object explicitly in HttpSession object and you can manage this object on your own.

I am not sure about the "sessionId"/ page 53 thing you mentioned
 
jack catler
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Varun,

Thanks for the reply. I will try to explain me dribbly question. ;-)

For both methods you mention, the bean now being in 'session' scope for that specific user, what guarantees (if anything) that the 'same instance bean/object' will be used between ongoing communication from browser to server for that specific user?

In other words, if I store some user specific details in the bean for the current user I am communicating with, when I go back into that session and try to access that bean, how does the backend (server) know what session (and thus what bean/object) is mine? Example application I guess would be like a shopping cart.

This is mentioned in page 53 of the "Core JavaServer Faces" book by Geary, and it mentions one option of "URL WRiting" where the session is tracked by passing a session ID in the URL. Not something I really want to do.

Maybe I am missing something but I am wondering what is the 'normal thing' to do in this case.

Thanks
Jack
 
jack catler
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok I am a bit further on this...the wonders of reading things properly...

It seems the JSF tags handles this automatically and perform the URL rewriting (i.e. adds the sessionID) for you to the page. I found this out be doing a simple 'view source' on the example on chapter 2 from the same book above....

So, my question 'now' is, ...is this the only way (aside from cookies) ?and, is this safe, i.e. any security issues with this ?

Any help from the "session guru's" appreciated.

Thanks!
 
Tim Holloway
Bartender
Posts: 18420
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This isn't really that much about JSF as it is about general J2EE session handling.

Normally the user's session is tracked via a cookie. If the user's browser refuses to accept cookies, the server will switch to URL rewriting - assuming that you've specified URLs in a rewrite-friendly way, which includes most JSP taglibrary-generated URLs.

The session ID is a "junk" value, something that has no inherent meaning and cannot easily be spoofed or reverse-engineered. You should, of course, never pass sensitive information to and from the client in cookies (or URLs), because unscrupulous people can hack the info and do Bad Things to you. However, since the session ID is simply a handle used to locate session info that never leaves the server, it's about as safe as anything is on the Internet.

In practical usage, you should avoid using the session API in JSF beans. First, because the JSF framework can inject them into your beans without the need for you to write session code, and secondly because good JSF code doesn't call server-specific methods unless it positively must. An "ideal" JSF bean is a POJO that can be tested without having to bring up a container at all.

JSF isn't doing any special magic with session info, BTW. Servlets and other non-JSF components (including taglibs) can access JSF session information using the Http Session set/get methods. JSF used the logical bean name as the session object's key.
 
jack catler
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim,

Very helpful summary and explanation!

Thanks guys!
 
Martijn de Bruijn
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should be aware of the problems of using the http sessions in combination with load balancing/fail over.
the session is stored in memory of the server. Therefore the data is only available when the next request is handled by the same server. If you have more than one server you needs some kind of session affinity in your load balancer to redirect the request to the same server each time. (in that case fail over is still not working)

For a shopping cart example I would suggest storing the basket in the database. This makes the load balancing a lot easier.

Martijn de Bruijn
 
Tim Holloway
Bartender
Posts: 18420
60
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, that's not entirely true. If you're using a feature like the Tomcat clustering facility, if one server fails, the session objects will be passed over to a recovery server.

However, to make that work, you have to make sure that everything you need to maintain in session is stored in a session-scope object and that that object both declares itself as Serializable (implements java.io.Serializable) and that the object actually is serializable, since declaring the interface is merely making a promise and to make things failover, you actually have to keep that promise.

Making objects serializable is required since to get data out of one Tomcat's JVM and into a failover Tomcat's JVM you need to have it in an externally-transmissible/saveable format.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!