inline responses... On Oct 1, 4:22 am, nogridbag <[EMAIL PROTECTED]> wrote: > > 1) If we can't trust cookies, what's the point of using cookies at > all?
As a storage space to save the session ID between sessions. Users do sometimes close their web browsers, or at least the tab with your page on it. I know. Those bastards! Incidentally, those same blasted users get very miffed if they have to enter a password every time they revisit your page. > > 2) That leads me to my next question, how should the sessionID be > stored in the client? Do I just store it in some class, let's say > User.java as a String or whatnot in plain text? Yes. > > 3) Then, in any RPC request that needs the user to be logged in, I > pass this session ID along with the rest of the objects? Well, usually you pass one object, which might contain a number of other objects, -and- the sessionID. Your server, in turn, looks only at that and completely ignores the cookie. In fact, if you want to get real fancy, you kill the cookie, and add a window closing hook, and re- add it, but because that hook doesn't get called with certainty when your page is going away, that's a bad idea. You could get fancy and kill the cookie, send your request AND start a 5 millisecond timer, and re-add it. I haven't tried this myself yet, seemed overkill given that my server is 100% SSL. > 4) How does the server then take this sessionId and authenticate it? Depends on your framework. Don't let your framework run its own session id management; they stuff it and look at the cookie, or they add it to all generated URLs. (if they do this without you telling it to in a setting, get rid of this framework right now. It's a blatent security issue that's been known for years. If they haven't fixed that, I really wouldn't trust them with anything else). If your framework doesn't support manual session ID management, then you'll have to manually manage the entire session. Annoying. Consider mailing your framework authors to add the ability to manually manage just the session tokens. (e.g: two methods - one with: generate me a new session ID please, and another with: Here's a session ID. Fetch me the session object. Or, if session querying is built in, a method with: Here's a session ID. Consider that this request has been sent with this session ID from here on out). > > 5) Finally, is there any situation where you would store the username/ > pass on the client in order to authenticate each RPC call? If so, > what would be the security implications of this? They wouldn't be very good. Don't do this. First of all, its very inflexible: Without both SSL and a requirement to re-login everytime you revisit the page, you've got a serious security issue, for example. Maybe you want your webapp to work that way, but what are you going to do if your client says: Weeeeell, turns out we do want logins to persist, at least for a little while. Or even: We want the ability to open a link in a new tab (that's a new 'session' after all!) - then you need to hack in a session system. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
