tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marian Simpetru <>
Subject JSESSIONID and impact on google
Date Tue, 09 Feb 2010 14:31:02 GMT

I run a tomcat-based portal (Liferay) and we did nice work with it. When
it came to google, we realized we are punished for using tomcat, since
there seems to be no way in disabling jsessionid (session id appended to
URL). Google act as a non cookie browser and hence he is served with non
unique URLs (because of session ID is appended to URL).

I think is a shame for google not being able to strip that part, but
that's life.

Question is: Is there a way to configure tomcat to only use cookies (not
append jsessionid to URL for cookie0less browsers). I've been told Jetty
or resin is configurable in this aspect.

Also the name ' JSESSIONID' is configurable?

Maybe a better idea would be that someone from Apache Tomcat should push
to google with some standards tomcat implement in this respect so that
google change the algorithm and not punish with low ranking websites
powered by tomcat.

Any other suggestion?

Marian Simpetru

> GOOGLE - This answer is for your question ! Thank you !
> Using URL-encoded sessions can damage your search engine placement
> To prevent abuse, search engines such as Google associate web content
> a single URL, and penalize sites which have identical content
> from multiple, unique URLs. Because a URL-encoded session is unique
> visit, multiple visits by the same search engine bot will return
> content with different URLs. This is not an uncommon problem; a test 
> search for ;jsessionid in URLs returned around 79 million search
> It's a security risk
> Because the session identifier is included in the URL, an attacker
> potentially impersonate a victim by getting the victim to follow a 
> session-encoded URL to your site. If the victim logs in, the attacker
> logged in as well - exposing any personal or confidential information
> victim has access to. This can be mitigated somewhat by using short 
> timeouts on sessions, but that tends to annoy legitimate users.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message