Issue #22 is back, Google's own CSRF protection DOES NOT handle glassfish/jetty multiple JSESSIONID

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Glassfish- visit admin console (http://host:4848/) creates JSESSIONID cookie 
for / , visit WPS (http://host:8080/WPS) creates JSESSIONID cookie for /WPS
2. Although on different ports, cookie spec doesn't care and both instances of 
JSESSIONID cookie are in scope to WPS, the GWT Google code sees both when it 
calls getCookie() and throws an exception "java.lang.IllegalArgumentException: 
Duplicate cookie! Cookie override attack?" and doesn't allow any requests to 
work.

1. Jetty- visit one of their sample servlets (i.e. http://host:8080/dump/info) 
creates JSESSIONID cookie for / , visit WPS (http://host:8080/WPS) creates 
JSESSIONID cookie for /WPS
2. Although different contexts, Jetty servlet sets its at root path so both are 
in scope to WPS, blah blah blah same exception and reason as the Glassfish 
example above.

There is no way to configure the GWT code to ignore the duplicate cookie check 
without modifying their code.  It would be ideal if it just checked for and 
cared about the cookies defined in the /WPS context and ignored the others or 
allowed a way to configure it to call Util.getCookie() passing true (allow 
duplicates) as the last parameter rather than hardcoding false.

The workaround when I had this same issue when I was rolling out my own 
CSRF/XSRF protection code back in WebPasswordSafe v1.0 was to use a different 
cookie name that basically just duplicated the last JSESSIONID value.  You'd 
think if this new way was Google's "official" documented and mandated way to 
protect against CSRF, even using JSESSIONID as the default example way, it 
would "just work" out of the box.  But clearly not, unless they never tested 
GWT code with this enabled using Jetty or Glassfish.  Very surprising.

What is the expected output? What do you see instead?

It should "just work" and handle all real-life scenarios of JSESSIONID in 
different Java Servlet Containers especially when they say that is what should 
be used as the "authentication cookie" in their examples (and I agree, not 
using the default servlet session and rolling out your own application specific 
sessions/cookies I think is bad practice) or at least say in their 
documentation the caveats and how people should handle those cases.  In the 
mean time I'll probably kludge and merge back in part of the logic I used in 
the previous version yet still fit the new CSRF protection scheme in the new 
version.

Original issue reported on code.google.com by joshdrum...@gmail.com on 1 Jun 2012 at 6:07

[GoogleCodeExporter]

Original comment by joshdrum...@gmail.com on 1 Jun 2012 at 7:24

• Changed state: Fixed

[GoogleCodeExporter]

https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/yaU-JSNICV
0

Original comment by joshdrum...@gmail.com on 2 Jun 2012 at 6:13