Thanks for the feedback Shawn and Reinier. I'm not relying on Cookies at all, the Session ID will be created by the server, it will be a large pseudo random number. The session IDs will of course expire.
Interesting point about problems that could be created by restricting access to a single IP, I will drop that approach. I'd like to use SSL - but I don't think it's practical, I do have root access to the server, but it's not my server. I'll post again when it's done and let you all know how it all worked out! On Dec 4, 7:24 am, Shawn Pearce <[EMAIL PROTECTED]> wrote: > Also restricting a session to a single IP address can be problematic with > some providers that use web proxies for their clients. I don't know if this > has changed, but years ago AOL made this rather difficult as requests from > clients can be routed out through multiple proxy servers. Individual users > bounced around on IP addresses between requests, based on the proxy server > load balancing algorithm used. My last employer did this with their > corporate desktops too, and there it was a matter of load-balancing the > outgoing traffic through different T3 connections. Its more common than you > might think. > > If you really need to protect the session, use SSL. Otherwise, probably the > best you can do is a time-based session token. Trying to tie it to an IP > address is just asking for some difficulty with proxies. > > On Wed, Dec 3, 2008 at 18:46, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote: > > > > > krona: If you are getting the session ID from the cookie, your web > > service is still vulnerable to XSRF (wikipedia it). Make GWT send the > > session ID in the body of requests (such as a parameter to GWT-RPC or > > stuff it in the JSON you're sending to your PHP). > > > On Dec 4, 1:24 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > > The approach I'm taking, and I'm hoping it is a good one, is to divide > > > the operations on the server cleanly in to read and write. I'm using > > > php on the server and GWT on the client. The client cannot execute any > > > write operation on the server without a unique Session ID, the only > > > way that the client can get a Session ID is by providing correct log > > > in credentials to the server. Once the client has provided correct > > > login credentials the server creates a Session ID and binds it to an > > > IP address. Any write requests coming in to the server will not be > > > honoured if they do not come from the IP address/Session ID > > > combination that the server understands as being 'safe'. Obviously > > > once write access is granted on the server all string data is stripped/ > > > escaped as appropriate. The philosophy is that the server will never > > > send anything to the client that could be intepreted as anything but > > > plain text. > > > > I cannot protect against fishing, but then this is only for a cat club > > > website! --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
