XSRF Issues with JIRA Cloud POST of Attachments from Javascript

We’re developing a JIRA Cloud add-in similar to our currently shipping Confluence Cloud add-in.

Our add-in is completely in HTML/Javascript using the all.js bridging library loaded dynamically from the JIRA Cloud instance and then using the AP object for all JIRA services, primarily the request object.

In Confluence we are able to save attachments to the page using the Confluence attachments REST APIs and AP.request with the the proper headers:

“X-Atlassian-Token”: “nocheck”

But no matter what we do on JIRA Cloud with the JIRA specific attachment create REST APIs called with a POST using the AP supplied request object, I get back a failed POST with an XSRF error.

As suggested some other posts on the forum, I tried “no-check” for the header, even tried walking the all-debug.js calls, but nothing helps.

I thought that this is exactly what the bridging library was supposed to allow to work.

This is absolutely different behavior from Confluence Cloud and prevents us from shipping our add-on.

The same attachment REST APIs work just fine with essentially the same sequence on JIRA Server.

I was told that Dave Meyer might have some insight on this.

Cheers and thanks,

Michael Eskin
SmartDraw

Hi Michael,

Can you confirm your add-on has ‘write’ scope, and provide your AP.request code please?
Many add-ons add attachments so we should be able to get to the bottom of it.

cheers,
David Boyd
Atlassian Connect

1 Like

Hi David,

I confirmed we have write scope in the manifest.

Here’s the essence of the code to write the attachment, same pattern works fine in Confluence Cloud, Confluence Server, and JIRA Server add-ins:

  function saveAttachment(theDataToSave) {

    // theDataToSave is a large block of base-64 encoded binary data
    theFileName = "testattachment.sdr64";

    // Make a blob from the SDR data    
    var theBlob = new Blob([theDataToSave], {
      type: 'text/plain; charset="UTF-8"'
    });

    var formData = new FormData();

    formData.append("file", theBlob, theFileName);

    var theRequestURL;

    // gContentId is the JIRA issue ID, previously obtained in the code
    theRequestURL = '/rest/api/2/issue/' + gContentId + '/attachments';

    AP.request({
      url: theRequestURL,
      type: 'POST',
      data: formData,
      dataType: 'json',
      async: true,
      processData: false,
      contentType: false,
      headers: {
        "X-Atlassian-Token": "no-check"  // Tried nocheck as well as nocache, same issue
      },
      success: function(theResponse) {

        debugger;
        
        // Kick off the next step after the save...

      },
      error: function(xhr, textStatus, errorThrown) {
      // We hit this every time with an XSRF issue
        debugger;

        alert("Problem saving data: "+xhr.responseText);

      }
    });

  };

Thanks,

Michael

Hi Michael,

Thanks very much for the example code.
If I change the contentType to:

contentType: 'multipart/form-data',

Then it seems to work for me. Can you see if that helps please?

Regards,
David Boyd
Atlassian Connect

2 Likes

Thanks, I had that in my Confluence Cloud version and had forgotten to bring it over to JIRA. Working now!

David, any way after our add-in POSTs the attachments and they are added to the JIRA issue to have JIRA Cloud refresh the page? I notice that after we add attachments and close our add-in dialog, I have to manually refresh the page to get JIRA Cloud to show them in the Attachments area. On our Server version, I’m able to manually force a refresh since we’re living the same DOM as JIRA, not in a sandboxed iframe. Not a deal killer, but a bit of an annoyance…

Hi @michaele
Sorry for the delay. Have you tried AP.jira.refreshIssuePage();?

If that doesn’t achieve what you want, I’d recommend raising a feature request

Regards,
David

1 Like

Yes, that’s what I ended up doing. Thanks!