9 Replies Latest reply on Sep 19, 2016 1:13 PM by noelwhite

    Content Viewer widget and red bar error loading document

    evan.schott Employee Sep 7, 2016 10:16 AM

      Noel White, there is a red bar error in the widget when loading the document. The document loads, but it does not load comments data. To give you visibility on the issue and get your feedback on the issue I've copied some notes over.

       

      The error is coming from an API call to getComments. I have posted the request and response below:

      Request:

      POST /__services/v2/rest/office/api/getComments/3863?time=1472498991372&docVersion=1 HTTP/1.1

      Host: healthstream.hosted.jivesoftware.com

      Connection: keep-alive

      Content-Length: 10

      Pragma: no-cache

      Cache-Control: no-cache

      Origin: https://healthstream.hosted.jivesoftware.com

      X-J-Token: ""

      X-Requested-With: ShockwaveFlash/22.0.0.209

      User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36

      Content-Type: application/x-www-form-urlencoded

      Accept: */*

      Referer: https://healthstream.hosted.jivesoftware.com/conversion-viewer.jspa?conversionMetaDataID=3863

      Accept-Encoding: gzip, deflate, br

      Accept-Language: en-US,en;q=0.8,de;q=0.6

       

      Response:

      HTTP/1.1 403 Forbidden

      Date: Mon, 29 Aug 2016 19:29:51 GMT

      Server: Apache

      X-Jive-Request-Id: f4aef600-6e1e-11e6-a5f7-005056a21b0e

      X-Jive-Flow-Id: f4aef601-6e1e-11e6-a5f7-005056a21b0e

      X-Frame-Options: SAMEORIGIN

      P3P: CP="CAO PSA OUR"

      Content-Type: application/json

      Expires: Mon, 29 Aug 2016 19:29:51 GMT

      Vary: Accept-Encoding,User-Agent

      Content-Encoding: gzip

      Cache-Control: no-store, no-cache, must-revalidate, private, max-age=0

      X-JSL: D=3885 t=1472498991455832

      Content-Length: 124

      Keep-Alive: timeout=5, max=99

      Connection: Keep-Alive

      The issue seems to be an authentication error. To be sure, I tried this from a command line making the request directly:

      $curl -i -u "admin:<password>" -XPOST "https://healthstream.hosted.jivesoftware.com/__services/v2/rest/office/api/getComments/3878?time=1472492622584&docVersion=1"

      HTTP/1.1 403 Forbidden

      Date: Mon, 29 Aug 2016 18:19:23 GMT

      Server: Apache

      X-Jive-Request-Id: 1ca91370-6e15-11e6-a5f7-005056a21b0e

      X-Jive-Flow-Id: 1ca91371-6e15-11e6-a5f7-005056a21b0e

      X-Frame-Options: SAMEORIGIN

      P3P: CP="CAO PSA OUR"

      Content-Type: application/json

      Expires: Mon, 29 Aug 2016 18:19:23 GMT

      Vary: Accept-Encoding,User-Agent

      Cache-Control: no-store, no-cache, must-revalidate, private, max-age=0

      X-JSL: D=3868 t=1472494763558842

       

      {

        "code" : 4026,

        "message" : "The request could not be validated as originating from within the SBS application"

      }

      This API request endpoint only accepts requests that come from within the application.

      Next I loaded one of the docs directly: https://healthstream.hosted.jivesoftware.com/docs/DOC-3181

      This generated the same request (so the request itself doesn't come from the widget):

      Request:

      POST /__services/v2/rest/office/api/getComments/3863?time=1472506517241&docVersion=1 HTTP/1.1

      Host: healthstream.hosted.jivesoftware.com

      Connection: keep-alive

      Content-Length: 10

      Pragma: no-cache

      Cache-Control: no-cache

      Origin: https://healthstream.hosted.jivesoftware.com

      X-J-Token: 6b2f612d184228a088b064f11c9895f44e3dd494f21350c7ce25a18cbd9b4d34

      X-Requested-With: ShockwaveFlash/22.0.0.209

      User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36

      Content-Type: application/x-www-form-urlencoded

      Accept: */*

      Referer: https://healthstream.hosted.jivesoftware.com/conversion-viewer.jspa?conversionMetaDataID=3863

      Accept-Encoding: gzip, deflate, br

      Accept-Language: en-US,en;q=0.8,de;q=0.6

       

      Response:

      HTTP/1.1 200 OK

      Date: Mon, 29 Aug 2016 21:35:17 GMT

      Server: Apache

      X-Jive-Request-Id: 7a796340-6e30-11e6-a5f7-005056a21b0e

      X-Jive-Flow-Id: 7a796341-6e30-11e6-a5f7-005056a21b0e

      X-Frame-Options: SAMEORIGIN

      P3P: CP="CAO PSA OUR"

      Content-Type: application/json

      Expires: Mon, 29 Aug 2016 21:35:17 GMT

      Vary: Accept-Encoding,User-Agent

      Content-Encoding: gzip

      Cache-Control: no-store, no-cache, must-revalidate, private, max-age=0

      X-JSL: D=13838 t=1472506517363554

      Keep-Alive: timeout=5, max=98

      Connection: Keep-Alive

      Transfer-Encoding: chunked

      The request from the widget is missing the header parameter X-J-Token

       

      Adding this to the header in my curl statement changed the return code to :

      {

        "code" : 4005,

        "message" : "Current user has no permission to request the conversion metadata of id 3878"

      }

      Which is a step in the right direction.

       

      Noel White can you take a look at the request header for the X-J-Token and see how the widget is handling this parameter?

       

      Shara Karasic

      • 389 Views
      • Tags:
        • Re: Content Viewer widget and red bar error loading document
          noelwhite
          noelwhite Sep 6, 2016 3:15 PM (in response to evan.schott)

          OK, this is starting to make some sense, and get more confusing.  Jive's "conversion-viewer.jspa" has two parts to it.  One is loading the SWF version of the converted Microsoft content, and another part is loading in in-line comments users can make onto the preview.  We have to block the in-line comments functionality in the document preview pane as there is no way to retain them, so they break our regulatory compliance rules.  This explains why we do not see this in our instances.  The confusing thing is I tested this in a new sandbox instance when Shara first reported this.  That instance was a single server instance and does not have an LTM with the irules to block the inline comments.  I thought that had eliminated that as the culprit, but the issue seems to be coming back to that explanation.

           

          For clarification, this is not a plug-in.  This is simply JavaScript code running in an HTML Widget.  I just wanted to avoid confusing anyone that could stumble onto this thread.

          1 person found this helpful
          • Re: Content Viewer widget and red bar error loading document
            noelwhite
            noelwhite Sep 6, 2016 4:29 PM (in response to evan.schott)

            Update:

            I just tested in a vanilla 8.0.4 instance where we do not have the iRule on the LTM to block the in-line comments.  The document preview is working fine with the in-line comments working as expected, and no error bar displays when the page loads...

            I have the same blank X-J-Token in the ShockwaveFlash request header, but no error bar...

            I tested in IE11, Chrome, and FF with the same results.

            2 people found this helpful
            • Re: Content Viewer widget and red bar error loading document
              evan.schott Employee Sep 9, 2016 10:18 AM (in response to evan.schott)

              Hi Noel, ultimately the X-J-Token header will be required for the code to work properly in this widget. There was a security fix for CSRF attacks but it didn't handle the headers properly, i.e. you could still make the call with the headers removed in certain cases. I think this is why it works for you locally and doesn't work where the iRules are in place. The system property is there to bypass this fix to allow the call to work, but exposes the security hole, so this is not a recommended solution.

               

              There are fixes in place in the latest version (JIVE-71371 for custom/hosted) that fix the issue with how the headers are handled, but ultimately require the X-J-Token and X-Requested-With headers. We'll be testing this on HealthStream's instance and I expect that it will affect the functionality of the widget.

                • Re: Content Viewer widget and red bar error loading document
                  noelwhite
                  noelwhite Sep 9, 2016 10:36 AM (in response to evan.schott)

                  Understood evan , and thank you for your research and feedback.  Ultimately, my code is not making this call, though.  It is the Jive code in conversion-viewer.jspa that is doing it.  Hopefully, I can add whatever you recommend to the iframe around that, or whatever is needed to make that call work in a secure manner.  Let me know what you find with your testing, and I will get your recommendations in place to get it functioning with those fixes.  Thank you again for reaching out.

                  • Re: Content Viewer widget and red bar error loading document
                    noelwhite
                    noelwhite Sep 19, 2016 1:13 PM (in response to evan.schott)

                    Evan Schott I started looking at supporting Jive's use of the X-J-Token and have an issue in our 8.0.4 on-prem instance.  Any time I have the system property jive.rest.internal.csrf.token.enabled  = false none of the content pages load without the following error bar:

                    Again, this is on a regular Uploaded File page of a Word Doc.  The Document Preview is not loading, and I get that error.  If urn off that system property, everything functions normally.  Again, the error on this page has nothing to do with any HTML widgets or such.  Let me know if there are additional properties that need to be put in place for this to work properly, and I will be able to test this properly and hopefully resolve it.