My plan is not no make another facebook :) is just a small erp. that initially will run into a VPN but i would like to expose as a web app in the near future.
I uderstood the advandatges of keeping the server stateless ,security,failover since session are not going to be replicated from fasiled server and so on. BUT :"The only way to be *completely* secure is to encrypt all wire traffic" How can i do that ? What are the drawback on this except a little bit slower application ? Thx a lot for prev answers to all of u ! On 6 Iul, 10:23, "brett.wooldridge" <[email protected]> wrote: > 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- Ascundeţi textul citat - > > - Afişare text în citat - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
