It really depends on your application. If you have 100 simultaneous users, sure go ahead and use server sessions. If you are designing the next gmail, ebay, or facebook, then server-side conversional state is a HUGE scalability mistake. Ebay, for example, is [almost] completely stateless (on the server).
For security there are many options. One of the most common is for the server to generate a security token of some sort during login that is returned to the client. Google (at least the Google Wave guys) would probably say using a cookie to pass it back to the server is a mistake -- pass it on every RPC instead. This can avoid some cross-site scripting attacks. Remember, cookies are automatically sent by the browser to the server. If you pass it by RPC, then YOU control when/if it is sent. But really, that part is your call. The principal is the same. The server can validate (yes, on every call) whether the security token is (still) valid. This is no costlier CPU-wise than a servlet- session lookup, and the memory reduction costs and fail-over advantages are a big win. Using servlet-sessions is no more (and probably less) secure. With typical server-sessions when a user authenticates (presumably over SSL) a cookie is returned. That cookie is all that is required to access the session-state on the server. Unless every request is encrypted, it passes in the clear. So, in the end, the more "state" you can keep on the client, the less susceptible it is to access by an attacker. The only way to be *completely* secure is to encrypt all wire traffic. Short of that, there is no security advantage of server-sessions. There are in fact more disadvantages, as noted, due to the accessibility of server-state given knowledge of the session cookie. As an aside, you can theoretically mutate the security token upon every request, this avoiding a "replay" attack and "out-of-sequence" requests that indicate a man-in-the-middle attack can be detected. In general, that kind of security is completely overkill. If you're writing a banking or financial application, just use SSL and be done with it -- rolling your own security is likely to have holes and attack vectors you never imagined. -Brett On Jul 3, 1:59 pm, ytrewqsm <[email protected]> wrote: > I read this on with several ocassions while reading about GWT. > > Now can anyone clear this for me ? > > 1)What this means that on server side is recommended not to use > servlet session ? > > 2)How can i secure the application if the client only has state and > server is stateless ? > > 3)BTW Each time i pass credential on method calls ? Is that not > something insecure ? > > 4)How can those be passed securely ? > > THX --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
