Hi Walden,
thanks for the answers. Sorry, I have to ask you again: You answerd:
> Once you've ascertained the user's identity and bound it to the
> session, sure.
Do you mean that one should use the session object to identify the
user for each request? Because my question was negated
("...recommandable not to use a HttpSession...")?
To my alternative suggestion:
What I mean is when the user logs in then I generated a random id that
identifies him a long as he is on my page. This means he recieves this
id from the server on the login procedure and the server on the other
hand also keeps this id. If the user now sends any request to the
server, then the user sends everytime also this id, such that the
server can verify that this user is logged in. If the user does not
continue to use my webage then after for example 30 minutes or so this
random id is deleted on the server side and the user is regarded as
logged out. Or it is deleted when the user logs out manually.
On 27 Okt., 21:17, walden <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
