Blank Page or Missing XSRF Token when CSV Import
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Problem
Bulk Create issues from CSV will fail. Users will face a blank screen or hit into "XSRF Security Token Missing" message in the UI and no errors will be thrown in the logs
When making the following actions...
- Create a simple CSV file
- Import this CSV either via Import issues from CSV or External System Import > CSV
- Just map the Summary
- Click on the Begin Import button
- Users will be redirected to a blank page (or see "XSRF Security Token Missing")
Disabling XSRF using jira.xsrf.enabled=false
will have External System Import > CSV hit a blank page as well.
Diagnosis
Environment
- JIRA installed on Linux/Unix environment
Diagnostic Steps
- Ensure the JIRA version and Tomcat version are not affected by - JRA-61179Getting issue details... STATUS
- Verify that same behaviour and is affecting all browsers including browser's private mode
- If customer behind proxy, ensure it is configured correctly referring to https://confluence.atlassian.com/kb/integrating-apache-http-server-reverse-proxy-with-jira-753894357.html
- Gather HAR file and verify there is no error thrown on the HTTP Status redirection
- Gather additional DEBUG logging of the
webwork.multipart.MultiPartRequestWrapper
package and the following appears in theatlassian-jira.log
2016-10-10 15:00:25,535 http-nio-8080-exec-16 DEBUG IAMADMIN 900x169173x1 b58w5h 172.16.215.22,172.16.141.212 /secure/admin/CsvSetupPage.jspa [webwork.action.ActionSupport] Action executed in 0 ms
2016-10-10 15:00:25,537 http-nio-8080-exec-16 ERROR [webwork.multipart.MultiPartRequestWrapper] null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at webwork.multipart.MultiPartRequestWrapper.<init>(MultiPartRequestWrapper.java:56)
... 2 filtered
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
... 89 filtered
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.IOException: Directory [/lokasi/jira/work/Catalina/localhost/jiracontextpath] is readonly.
at http.utils.multipartrequest.MultipartRequest.initParser(MultipartRequest.java:593)
at http.utils.multipartrequest.MultipartRequest.<init>(MultipartRequest.java:488)
at http.utils.multipartrequest.ServletMultipartRequest.<init>(ServletMultipartRequest.java:162)
at webwork.multipart.PellMultiPartRequest.<init>(PellMultiPartRequest.java:81)
at com.atlassian.jira.web.JiraMultipartRequestWrapper.<init>(JiraMultipartRequestWrapper.java:26)
Ask for
ls -lah /lokasi/jira/work/Catalina/localhost/
and something similar to the following returned which show the userjira
do not have full permissionjira@testserver:~$ ls -lah /lokasi/jira/work/Catalina/localhost/ total 0 drwxrwsr-x 4 jira jiraadmin 37 Jul 28 12:05 . drwxrwsr-x 3 jira jiraadmin 22 Jul 25 16:11 .. drwxrwsr-x 2 juser jiraadmin 6 Jul 28 12:05 jiracontextpath
Cause
This is caused by the WORK directory of Tomcat is read-only by the user jira
that runs JIRA application.
Resolution
Ensure the user that is running JIRA have all the permission necessary.