Hi Paul,
Responses inline...
On Oct 27, 6:50 pm, Paul van Hoven <[EMAIL PROTECTED]>
wrote:
> 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...")?
No, sorry. I read carelessly. First, I think using a session object
to identify the requestor is not the best idea. Second, yes many
applications do that, but what I was pointing out that this does not
replace an authentication protocol.
>
> 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.
That is essentially your handmade rendition of a session token. It's
no better or worse than JSESSIONID, provided that there has been a
successful exchange of credentials. In fact, it's worse, because it
intrudes into your application data semantics (ie., it pollutes your
RPC requests).
If you setup Digest authentication, the browser and the server would
negotiate credentials following a login prompt, then all your future
requests will carry both an identity and a credential (which can
change over time), without you having to program those into your RPC
API. If you need logouts and/or session expiration, then you will
need to do some work.
Walden
>
> 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- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
