On 31 mar, 12:55, Ivan M <[email protected]> wrote:
> Being a newbie I can't fully understand the superiority of the client-
> side approach over Magius' session solution. As far as I understand,
> keeping the user's credentials in the client means they must be sent
> to the server and this must verify them in every service request.
> However, with Magius' solution, verification can be done once for the
> entire session. Where am I wrong?.
Every request has to be secured and "verified" on the server side.
Whether you pass a login/password pair or a "ticket" (that could be
your session ID, managed "transparently" by your server's session
handling feature) doesn't change much things, you still have to pass
along something that the server can check to make sure you're
authorized to make such a request.
With an HttpSession, you let the server do this "verification" for you
(and associate data with this "session"), but be careful about CSRF,
as securing an app against CSRF needs client-server cooperation
(cookies and "tokens in URLs" aren't secure *at all*
The thing is, a state-less server is (generally) easier to maintain
("reacting" to a request only depends on the request and on the
server's "data", not any previous state associated with the "user
session") and easier to scale (first: no need to maintain "sessions",
so it consumes less memory; then: need two servers instead of one?
just add the second server and set up a load balancer, no need for
session-sharing between your servers or "sticky-sessions" at the load-
balancer level), among other things.
But of course, YMMV.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
