On Oct 27, 2:43 pm, Paul van Hoven <[EMAIL PROTECTED]>
wrote:
> Someone told me not to use the HttpSession Object. Well, he wasn't
> able to justify it. But I'm wondering if it is recommandable not to
> use a HttpSession object to identify the user.
Once you've ascertained the user's identity and bound it to the
session, sure.
>
> Each time the client makes a RPC to the server, it does then send the
> HttpSession Id such that this user can be identified on the server
> side through his Session object by the container (in my case Tomcat)?
I think you're referring to the Java HTTP Session cookie called
'JSESSIONID'? Yes, this gets sent even on RPC calls.
>
> My alternative suggestion would be to store a unique generated userid
> (generated with my own code) and store this userid in some variable on
> the client side and send this userid with every RPC. On the server
> side user critical data is the mapped with this userid.
Generated when? At the end of the day, you need a protocol for client
and server to agree on identity, via a pre-arranged shared secret. Do
you mean to reinvent that protocol?
>
> And secondly: What happens if the user client does not accept cookies.
> Then the container would use URL rewriting to store the session id. In
> this case, does the container retrieve the session id if the user
> makes a RPC?
HTTP Basic or HTTP Digest cover all the issues above, with virtually
no effort on your part.
Walden
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
