Originally Posted by tangoforce
No I disagree. The session can't be attacked if its had all of its variables unset / deleted and can be recycled for another user on the same computer in a similar way to thread pooling in windows socket apps. Besides, the ID wasn't that of the session i meant.
What I meant, was put the USERS ID in the form so that it can be checked against the current user who logs in. If the two match, it's the correct user so process the stored http data. If its a different user id that has logged on then the data can be dumped or stored in the previous users account somewhere.
Ajax is also fine to use BUT it can be a pita on the browser and CPU resources.
Well, that's a spam hole in itself. I can do simple HTML injection and input an ID - probably starting sequentially - unless you use random IDs which I'm pretty sure not many do due to collision chances. Posting messages when logged out and they will be posted 'somewhere' in that users space...then post the messages with lets say my ruthless bots mate. What would your application be able to do about that? You might have a captcha or something...but that introduces an inconvenience by itself for logged in users. How about that?
Ajax is not so expensive now on resources...unless you're moving media files or you are on a free host(most have a limit to system pings). Messages will be served well by Ajax.