Skip navigation
Anil Saldanha

Tasty Cookies

Posted by Anil Saldanha Apr 25, 2005
Cookie is that goodie that is sent back to the client (Eg: Browser). It is a mechanism by which the server distinguishes client requests and maintains session on the server.

Documentation from Netscape on cookies can be found here:

A treatment on HTTP Session Management is here:


A Cookie is so tasty that somebody has a website for it:


I would like to remind users to always use response.setEncodeURL(url) to encode the url just in case the client's browser does not eat cookies.


Generally, users want to invalidate sessions on logout. So they invalidate the session on the serverside. But do send back a cookie with MaxAge set to 0, so that lingering session cookies in the browser do not create problems in your servlet code.


Cookie Max Age

Go get some cookies!!!
Section 1:


Last night I attended a good presentation on security. The presenter appraised the audience on securing web applications against SQL Injection, HTML injection, cross-site scripting and other things. He did mention that there are a whole bunch of legislations like HIPAA, SOX etc that as an external facing web app , you will have to comply. Now the question is "How much security is enough?"

Section 2:


J2EE provides decent security facility in the spec. You can create security settings in the web container, in the EJB container and all the way to the data access layer. When vendors provide products, they cannot assume reasonable defaults for security. Security is mostly disabled by default. Hence the responsibility of ensuring security in the application is on the developers developing the application. But the question is if the developers themselves are new to J2EE, new to Java , new to programming, is it possible for the application to embrace security? There is JAAS which provides a good pluggable framework for authentication and authorization in the Java world. Is it practical for developers to embrace JAAS or the container settings or Tomcat Valves etc to provide security as an aspect of the application, without instrumenting their business code? It should be. But is it??? This brings us to a good topic: importance of filters, handlers, valves and interceptors. These give me the options to plugin logging, security, tx and other aspects to my business code that can sit in servlets/EJBs/Web Service endpoints. I can get cleaner business code.

Section 3:


Providing security to anything in the computer world is viewed as an overhead but it is a necessity. Security and performance many times do not see eye to eye.

Section 4:


If I am a developer, - would I care about defensive programming? - would I care about maintainability of my code? - would I care to get it code reviewed? - would I think about good exception handling? - would I think about coding guidelines?


I SHOULD, right???

Section 5:


There is xml security that provides message level security and then there is transport level security (SSL). Message level security has some tangible benefits like you can encrypt portions of your message that needs to be secure. With SSL, the whole communication is secure. But the question is, is the xml encryption foolproof?

Section 6:


Identity Management, SAML, Liberty Alliance: One stop storage of credentials at providers. Applications will ask the provider for authentication/authorization, via assertions. Can these providers be foolproof?


As you can see that when I think of security, there are various directions in which my though process goes. I have listed them under various sections. What do you guys think?


Security is a ocean, where every ship needs to be, either reluctantly or with full consent.