How to identify website visitor when cookies disabled and URL rewriting is not allowed?

Question

In Java web application, Java servlet create unique jsessionid that passes as cookie to the client browser to keep track of the client's subsequent requests after the first one. But when cookies disabled and URL rewriting is not allowed due to security policy, my understanding is that Java servlet would create a new session object for every request from the same client. Is this correct? And does it mean a lot of wastage of server memory ( excessive memory allocation for each session object that is never going to be used again and excessive garbage collection)?

One solution is to use in such scenario is to use client's IP address and user agent string to uniquely identify the user and store in database. Is this correct solution?

Above scenario is fairly common in case of search engine bots which typically makes thousands of frequent requests when they visit the site.

Any other thoughts on crafting proper solution for this problem for a Java based web application?

Answer 1

Yes, in that situation sessions will be created every time. These do cost memory and will need to be GC'ed eventually.

If you don't need to track users you can always opt to disable the creation of sessions. In JSP this is a bit difficult, since a page normally always creates a session. There is a directive to turn this off though.

You can however write a filter and servlet request wrapper that prevents sessions from being created.

In JSF there is a very unfortunate bug in the much used Mojorra 2.04 implementation that makes it more or less impossible to do this, but luckily Mojarra 2.1.0 has fixed this.

In case that you really do need to track users, a form of fingerprinting could be used. This is always approximate though and I don't think you should ever use this for a login. IP + user agent is a form of fingerprinting, but because of proxies and large organizations installing the exact same browser for all their workstations this is quite unreliable . It's okay for usage statistics, but totally unsuited for logins.

Alternatives are using HTTPS/SSL, as this protocol has a build-in kind of "session ID", or using DOM or Flash storage, which not everyone who disables cookies also disables.