simple security

In a typical J2EE application there are various ways of of storing session state which include client-side cookies, the HttpSession object, database, an EJB, or even the POJO. Another place you can store the application state, in an encrypted form, is in the HTML page itself. Interesting read. Check it out here and here.

According to the article these are the pros and the cons of storing the state in the HTML itself:

Storing state on the client has the following benefits:

* Scalability - A single server can support more clients. An increase in clients does not require more memory or database resources on the server.
* Back Button is not a Problem - All state is saved in the page making the back button no longer an issue. What you see in the HTML page is the Java object used to generate that page.
* Session Time-Outs not an Issue - HttpSession time outs are not a problem.

Saving state on the client does not come for free. Here are some of the drawbacks:

* Computing Resources - There is a CPU cost associated with encoding/decoding and encrypting/decrypting of state for each interaction.
* Bandwidth - Since all the state related to a page is sent back to the server on each request there will be more data sent.
* Navigation must be from a form - The state is kept as HTML form hidden variables requiring page to page navigation to be from a form though links could use JavaScript to performs a form submits.
* Browser Crashes - If the browser that contains the state crashes the state is lost.