Scan Type Cleanup - CSRF Error

[Kate Alpert]

Dear all,

When trying to run a Scan Type Cleanup on a large project (>1500 sessions) in XNAT 1.6.3, we are getting an error: "Invalid submit value (POST on URL: https://nunda.northwestern.edu/nunda/app/action/ModifyScanTypes".  From looking at the code, it seems like this happens when the CSRF serverToken and the clientToken don't match (the excerpt from turbine.log is below).

In Chrome, it takes a few minutes for the Scan Type Cleanup page to even load for this project (Chrome sometimes asks if I want to kill the "unresponsive page").  The loading is faster in Firefox, but I still have the issue there.  

We do not have this problem when running Scan Type Cleanup on other (smaller) projects.

Please advise.

Thanks,

Kate

2015-02-24 12:02:48,433 [http-bio-8443-exec-216] ERROR org.apache.turbine.Turbine - Turbine.handleException:

java.lang.Exception: Invalid submit value (POST on URL: https://nunda.northwestern.edu/nunda/app/action/ModifyScanTypes from IP (XXX) user: IP

(and then a list of headers and cookies that I can send privately if needed)

        at org.nrg.xdat.turbine.modules.actions.SecureAction.isCsrfTokenOk(SecureAction.java:204)

        at org.nrg.xdat.turbine.modules.actions.SecureAction.isCsrfTokenOk(SecureAction.java:152)

        at org.nrg.xdat.turbine.modules.actions.SecureAction.isAuthorized(SecureAction.java:237)

        at org.apache.turbine.modules.actions.VelocitySecureAction.perform(VelocitySecureAction.java:59)

        at org.apache.turbine.modules.ActionLoader.exec(ActionLoader.java:96)

        at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:113)

        at org.apache.turbine.modules.Page.build(Page.java:53)

        at org.apache.turbine.modules.PageLoader.exec(PageLoader.java:98)

        at org.apache.turbine.Turbine.doGet(Turbine.java:751)

        at org.apache.turbine.Turbine.doPost(Turbine.java:846)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)

...

[McKay, Michael]

Kate, you may find the following thread helpful, particularly Jordan’s first comment: https://groups.google.com/forum/#!searchin/xnat_discussion/isCsrfTokenOk/xnat_discussion/vsmHwvn8-RY/8GFiIpbfEQAJ

 

The quickest solution would probably be to temporarily turn off CSRF checking via the admin configuration screen, run Scan Type Cleanup on the large project, and then turn it back on again. Jordan also suggests a couple other possible ways of getting around CSRF issues. Hopefully one of them will be sufficient for your purposes. Either way, let us know! Hopefully we can get this working for you.

 

-Mike

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

---

The material in this message is private and may contain Protected Healthcare Information (PHI). If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Kate Alpert]

Hi Mike,

Thanks for getting back to me.

In the short term, I'll turn off CSRF checking and let the user run the Cleanup.  I imagine that should work, although I'll keep you posted.

I'm not really satisfied with this as a solution, however.  Why would the CSRF check fail on a core XNAT feature (aka not a feature that I added or customized)?  And why only for certain projects?  This doesn't seem like something we should "get around", but rather, something that must be fixable!

Kate

[McKay, Michael]

My best guess is that the SQL query which updates the XNAT database is taking a very long time to execute because it has to update information for such a large number of sessions. To my knowledge, the CNDA, which uses the scan type cleanup feature and has a large amount of data, has not yet come across this problem. The best fix would probably be to add a loading page, so users can be taken somewhere while the SQL query is running. I will create a JIRA issue for this problem and suggest that as a possible fix, but I’m not sure how high of a priority it will be. If the workarounds are not working for you, or if anyone else has similar problems and has to resort to workarounds, please let us know so we can make this a top priority in our development efforts.

[Kate Alpert]

Hi Mike,

The error happens immediately after the user clicks submit, so I don't think the issue is the SQL query to change the data.  I would guess the issue happens because the page loading itself takes so long.  Could you (or Jordan) tell me more about how the server and client CSRF tokens are set with a page load (or point me to the relevant javascript/java code)?

Thanks!

Kate

[Tim Olsen]

I wouldn’t have thought that the CSRF would change mid session.  It does change if you have to re-login.  Is it taking so long that you have to re-login?

 

Tim

[Kate Alpert]

No, I don't have to re-login.  

This issue has been replicated with two different users and two different browsers.

[McKay, Michael]

Kate, could you view source on the Scan Type Cleanup page for the project where this is happening? I am wondering if the length of the page load is causing some of the CSRF information not to be included or to be incorrect. Can you then do a case insensitive search of the source for “csrf” and send me the lines containing it? I think there should be 4 mentions of “csrf” over 3 lines and the value of csrfToken should be the same as the value of el.name.

 

If you want to dig into the code for setting the CSRV token, I suggest looking at  Noninteractive.vm, HeaderInclues.vm, OnXnatLogin.java, and XnatBasicAuthenticationFilter.java.

[Kate Alpert]

Hi Mike,

The CSRF token appears in 2 places (I've replaced it with XXX, but it matches), and then in a YUI request.  Does this look correct:

89    var csrfToken = "XXX";

245   el.name = "XNAT_CSRF";
246   el.value = "XXX";

674   //YAHOO.util.Connect.asyncRequest('GET',this.obj.URL,this.initCallback,null,this);

675   YAHOO.util.Connect.asyncRequest('GET',serverRoot +'/REST/search/saved?XNAT_CSRF=" + window.csrfToken + "&format=json&stamp='+ (new Date()).getTime(),callback,null);

Kate

[Tim Olsen]

Kate and Mike,

 

I was looking at this code for a separate bug a few days ago.  The way the CSRF token is being added to that form is probably a javascript function in HeaderIncludes.vm (lines 245 and 246 from your reference).  That function will wait until the page is completely loaded and then add the CSRF token to any forms in the page.

 

Perhaps because your page is taking SOOOOOO LOOOONG to load, something is messing up and the CSRF isn’t being added to the form, or it isn’t being added before the user submits.

 

Another option is to just add the CSRF token directly to your form.  Try modifying XDATScreen_scanTypeCleanup.vm and add the following on line 15 (or right after the form is opened).

 

<input type=”hidden” name=”XNAT_CSRF” value=”$!XNAT_CSRF”/>

[Kate Alpert]

Thanks, Tim!  Is $XNAT_CSRF already added to the context by the java screen class, or do I need to add that, too?

[Tim Olsen]

It should already be there.  If not, you could pull it directly out of the http session with: $!data.getSession().getAttribute(“XNAT_CSRF”)

[Kate Alpert]

That seems to do the trick, thanks!