22 Replies Latest reply on Aug 26, 2016 5:27 AM by markus@tembosocial.com

    Access add-on back-end endpoints from Jive App

      I'm working on a Jive app that lives within an add-on using the Node/Express Jive-sdk.  The add-on is registered properly, etc.


      Whenever I make ajax calls from the app, they are sent to Jive instead of the app's backend.  This is in direct violation of the cross-domain nature of ajax, iframes, etc.


      For example, in an angular js app (or anything similar, really), I can have a GET endpoint at /tacobell that returns the most popular tacos.  For the sake of discussion, let's assume this service lives at http://localhost:3000/tacobell


      My jive instance is at:



      When I make an ajax call from the app (which lives at http://www.localhost:3000/app.html for the sake of discussion), some magic voodoo is happening which is causing my http call go to http://localhost:8080/tacobell, which is obviously an invalid endpoint.


      Is there a way to disable Jive from proxying http calls?  This is pretty much the bane of my existence.  I'm sure there is a reason for it - but it seems legacy to me w/ the whole add-on infrastructure.


      I would rather not use Jive Connects if possible.  I am using oauth to secure my endpoints, and Jive Connects can only used a fixed account so I do not have a reliable method of detecting which user is actually accessing them.


      Please advise ASAP.


      John Larson Ryan Rutan Tim Mila

        • Re: Access add-on back-end endpoints from Jive App

          Part of what is driving this is a situation where we upload a file to the node back-end for processing.  Imagine a data migration type deal.  Upload a CSV of content to manipulate, for example.


          I cannot figure out how to upload a file using the OSAPI api.  Is it possible to do this?  There are lots of really good ajax (angular or jquery) uploaders that I could use if I could hit my back-end directly.

          • Re: Access add-on back-end endpoints from Jive App

            Alright guys, I've been digging deep on this issue and I'm very close to having to a viable solution.  Having said that, the last part is the most challenging part.


            In a Jive app, as you know, Jive loads the content from the 3rd party HTML into the Jive domain.


            My "app" canvas view is an HTML page that contains an iframe that lives on the 3rd party domain and performs all of the logic w/ the backend, proper authentication, no style clashes (bootstrap works perfectly!), native templates/json/etc with angularjs, etc.  It is the bomb!


            Having said that, I have one more challenge to resolve:


            For this discussion, there will be mention of two HTML pages.  One will be the JiveApp, which is the page that jive loads into the Jive domain.  The other HTML page will be ExternalApp, which is the page that is loaded into the iframe of the JiveApp html page.


            When the JiveApp page is loaded into the standard jive page, I detect the height of the parent (since it's an iframe) and set the size of the frame accordingly.  This is good.  I then let the ExternalApp grow as big as it needs to, and then will generate a scroll bar when appropriate.  Also good!


            The hang up is when a user shrinks down their browser window.  This causes the original "app" page to shrink, but it does not notify the iframe of the JiveApp page.  I end up with two scrollbars.


            What options do I have in this regard?  If we can resolve this, this could potentially be huge for the platform.

              • Re: Access add-on back-end endpoints from Jive App

                One thing I am struggling to understand in your scenario: Are you not leveraging the Jive Javascript API for interacting with Jive. From your description it sounds like you are just embedded an external app. Correct?

                  • Re: Access add-on back-end endpoints from Jive App

                    Correct.  I'm trying to avoid using Jive code for the client.  I'm slowly building up a code set getting away from the Jive SDK for an add-on server as well.


                    In a perfect world, I want Jive to only be the authentication provider (oauth) and then just a rest interface that my add-on 3rd party server talks to w/ either a system user (in the case of run-as) or using the user's oauth token.

                      • Re: Access add-on back-end endpoints from Jive App
                        Ryan Rutan

                        Dan, apologies as this last statement caught me off-guard.  I get the moving away from the Jive SDK part (meaning you want to role your own service, which is fine), but I dont get the "using Jive only as authentication provider".  If you are using Jive Apps, those must be serviced from Jive.  If all you are trying to do is register an Add-On with Jive, so you can get a clientID/secret, then I'd recommend checking out this document:

                        OAuth 2.0 which has an example means of getting a clientID/secret without requiring a middleware service, and you can then use those keys to integrate.


                        Is that your scenario?  Hope that helps, if so =)

                          • Re: Access add-on back-end endpoints from Jive App

                            Out of curiosity, why is the content of the app proxied and displayed into into an iframe versus just displaying the add-on server's html page?  By doing this, you are not tied to the Jive stack.  You could still, in theory, have a communication API to allow resizing the iframe. 


                            Is it so you can access the REST api from the client?  I guess I assumed you'd want to make the Jive REST api calls via the add-on back-end, and be able to talk directly to the back-end server through standard HTTP calls instead of being proxied through Jive.

                              • Re: Access add-on back-end endpoints from Jive App

                                The main reason Jive (and any opensocial) apps are proxied through Jive/Shindig is so that you can

                                • Access content in Jive using the Javascript API
                                • Make requests to your backend service without cross-domain restrictions using the osapi.http methods
                                • Have the user authenticated to Jive without a separate login
                                • Have the ability to sign requests to your backend so you can validate that they are genuine
                                • Automatically have access to the context of the view (e.g. which group am I in, am I viewing this on a users profile, which discussion is currently open)

                                Doing all this with an pure iFrame approach would be very difficult if not impossible.


                                Nothing prevents you from embedding an iFrame in a Jive app view to show your backend. The only drawback would be that the user would have to authenticate to Jive again within your iFrame. ("Why is Jive asking me to login to Jive?" ;-) )

                                Getting the current context in Jive securely into your iFrame is also going to be more involved.


                                If you do not want to leverage the Javascript API this would be a feasible approach and you could even run the app standalone outside of Jive. We are actually doing this partially with a Jive app that utilizes webhooks.