On 7 juil, 10:20, Kwhit <kwhitting...@gmail.com> wrote:
> I'm interested in Dean's comments on performance impact of session
> data which seems counter intuitive to me (not that I doubt you at all
> Dean, just want to understand!)
>
> 1/ The session is going to be stored anyway right. That's part of the
> contract with the client. I don't know what this equates to in terms
> of bytes but I guess it's not less than a 100.

No!
A session is only created when needed (in Java servlet land, with a
default config). If you never ever call getSession(), you'll never
have the session overhead (and cookie). (you can also use getSession
(false) to check the existence of a session without creating one)

> 2/ ytrewqsm's original problem would be solved by storing one single
> long in the session: the user ID. The session is 'secure enough' for
> many applications (banking, etc., excepted).

Provided you disable cookie-less sessions and renew the session at
login, yes (session-fixation CSRF attacks are soooooo easy otherwise).

CSRF should be taken into account seriously on every web application
(think web mail such as GMail or Yahoo! Mail, social apps such as
Facebook and Twitter, etc. if someone can read your mails or send
mails/tweet/etc. on your behalf!)

> Each service request made
> by the client in the context of that session can be authenticated

Er, let's just say "attached to a given user".

> 3/ We can't, and don't need to avoid being platform specific - we are
> talking GAE not WebSphere, WebLogic, JBoss, ... My guess is that the
> session will be stored somewhere in BigTable and will be scalable.

Oh, if we're only talking about GAE, then yes, using Google Accounts-
based auth is probably the best choice. But if you roll your own auth
mechanism, it's really easy not to use servlet sessions, and therefore
achieve better security and scalability (that's a problem of sessions
too, when you start using a cluster)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to