The server can still know who the user is, if the user passes a security token back to the server. This token can either be in a cookie, or passed programatically though the RPC call. Typically it is generated when the user logs in. This is the same as when you set your gmail account to "stay logged in". There is a cookie, generated by Google when you logged in the first time that is served back to Google when you revisit www.gmail.com. No other site can access your site's cookie, even though JavaScript.
With respect to cross-site scripting, you simply have to code against it in this scenario. Or, if you use RPC to pass the token rather than relying on cookies, you don't have to worry about it at all. The token can be anything from a meaningless identifier to something sophisticated like a Blowfish encrypted version of the user's ID, allowing the server to validate who is making the request and ensuring it is against the correct account. This is not rocket science. It is indeed possible to write a stateless server that is completely secure and safe from cross-site scripting attacks. A stateless server will allow your application to scale to millions of simultaneous users. If, as I said in my first post, you have an application with only a few hundred simultaneous users then sure, go right ahead and build a stateful server. But you still have to guard against cross site scripting attacks, because every almost every stateful server will rely on cookies for session identification. Old-school URL-based session identifiers are even a worse security problem. -Brett On Jul 7, 1:11 am, Kwhit <kwhitting...@gmail.com> wrote: > I think ytrewqsm has a point. > > If user X has authenticated, the server can know which user it is > (stateful) and refuse to change (for example) another user's profile > in response to a "Change user Y's password to xyz" request. > > If the server is stateless and the logged in user state is held on the > client (recommended) then the server will innocently go ahead and > process the a spoofed change password request (and any other spoofed > request). > > I think that is what ytrewqsm is getting at --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
