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

Content Viewer widget and red bar error loading document

evan.schott 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

Re: Content Viewer widget and red bar error loading document

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
Like (0)

Actions
Re: Content Viewer widget and red bar error loading document

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
Like (1)

Actions
- Re: Content Viewer widget and red bar error loading document
  
  evan.schott Sep 7, 2016 11:34 AM (in response to noelwhite)
  
  Hi Noel,
  
  Thanks for looking into this on your end. That put me on the trail to check on CSRF bugs we've patched and it looks like it's related to a bug exposed when CSRF vulnerabilities were patched in a previous release.
  
  To test, I added the system property jive.rest.internal.csrf.token.enabled = false and the error went away.
  2 people found this helpful
  
  Like (2)
  
  Actions
  - Re: Content Viewer widget and red bar error loading document
    
    noelwhite Sep 7, 2016 11:42 AM (in response to evan.schott)
    
    Confirmed! I added that property set to true in my test instance, and voilla! There is the error!
    
    Like (1)
    
    Actions
    - Re: Content Viewer widget and red bar error loading document
      
      sharakarasic Sep 7, 2016 12:18 PM (in response to noelwhite)
      
      I added it to and the error went away too! Yay! Thanks so much you guys for your help.
      
      Like (2)
      
      Actions
    - Re: Content Viewer widget and red bar error loading document
      
      jgoldhammer Sep 8, 2016 1:26 AM (in response to noelwhite)
      
      Please be careful with this setting. This disables an important WEB security Feature of the platform and IMHO should be disabled only on test instances.
      1 person found this helpful
      
      Like (0)
      
      Actions
Re: Content Viewer widget and red bar error loading document

evan.schott 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.
Like (0)

Actions
- Re: Content Viewer widget and red bar error loading document
  
  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.
  
  Like (1)
  
  Actions
- Re: Content Viewer widget and red bar error loading document
  
  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.
  
  Like (0)
  
  Actions

Go to original post