Yeah...I like your solution. Any chance you could post samples of those
fixes (or email them to me)? I haven't done that before...
-Dave
On Wednesday, July 25, 2012 12:22:38 PM UTC-6, jhulford wrote:
If you are serving your nocache files with your app server you could make
a simple http
Sorry, i'm away from my workspace for several days. Just read up on the Sevlet
Filter interface and use your web.xml to associate it with requests for your
nocache files. In the filter's doFilter method essentially all you'll do is
call getSession to ensure a session is created and then pass
The session cookie should always be present because of your login process.
You don't need an XSRF token during login but once you have successfully
authenticated (and thus a session id is available) the very first thing to
do is to fetch a XSRF token from the server. So basically your login()
Thanks Alex Jens,
I have two separate applications where I'd like to use this approach
to protect against XSRF attacks.
In one of them I'm seeing this problem with GWT in hosted mode so
there is no login process at all. Eventually it will be put inside of
an enterprise ear and will have a
If you are serving your nocache files with your app server you could make a
simple http filter, associate it with nocache requests and establish a session
in the filter's service method. That way you know for certain you always have
a session when your host page loads. Since you have access
I've been switching my RPC calls to use XsrfTokenServiceServlet per this
link
https://developers.google.com/web-toolkit/articles/security_for_gwt_applications#cross-site
It's working quite well except that I occasionally get this error on the
first RPC method call.
Exception while
I just started implementing the same guide, and used a similar workaround
to you:
if (Cookies.getCookie(JSESSIONID) == null) // We must have a session
cookie in order to authenticate with the server
Cookies.setCookie(JSESSIONID, Double.toString(Math.random()));
XsrfTokenServiceAsync xsrf
