REST API presence in Content Server

Hello,

I would like to know how can we verify the presence of REST API in a Content Server instance and whether all the functions are present. Thanks

Glen

Comments

  • I observed using Fiddler that some APIs work while some do not especially with multiple calls from FolderWidget

  • You can have a look at the /apiinfo resource. I don't know, how far it works for CS core and optional module REST APIs.

    There is no resource in the current core CS REST API, which would tell you the CS update version, or the list of installed modules and their version, AFAIK.

  • Thanks Ferdinand. My issue was with Brava that was overwriting some REST API code. By uninstalled Brava, everything works as expected.

  • Could someone be more specific on this? We have noticed nothing with Brava installed, other than the widgets do not honor the 'open' event and pass through to Brava.

    I wish we could see Brava behaving within the Widgets.

  • About the CS REST API & Brava: We have not noticed any problem with Brava interfering with the CS REST API recently. But we work with the CS 16 and Brava for the CS 16.

    About the CS UI Widgets & Brava: You can customize the FolderBrowserWidget to get the desired Brava integration. For example, add a menu item for Brava, or override the default click action for documents to open the page with Brava.

    Brava was acquired by OpenText recently. There will be Brava integration available OOTB in the CS UI Widgets for the CS 16. Currently there are no plans to provide the integration for the CS UI Widgets for CS 10 or CS 10.5 (by OpenText).

  • Thanks Ferdinand, we are proceeding with the FolderBrowserWidget and look forward to the next release.

    We did note that we had issues with CORS errors until we got the Brava patch installed.

    .....Now if we can get OTDS / single sign-on to work, we will be ready to rock & roll.

  • Fernando-

    you indicate that you can override the default action for the FolderBrowserWidget. can you point to a code example of doing this? I don't see how you get the object id from the widget.

    Thanks

  • How to open a new browser window/tab, when a document is clicked on in the table:

    csui.onReady(function () {
      // Specify your server connection here
      var cgiUrl = '...',
          supportPath = '...';
      // Create the widget
      new csui.widget.FolderBrowserWidget({
        connection: {
          url: cgiUrl + '/api/v1',
          supportPath: supportPath
        }
      })
      // Listen to the event, which precedes the default click action execution
      .on('executingDefaultAction', function (args) {
        var node = args.node;
        // Handle documents in a special way
        if (node.type === 144) {
          // Open a new window with the Classic CS UI page
          window.open(cgiUrl + '?func=...&objAction=...&objId=' + node.id);
          // Prevent the default action handling in the widget
          args.cancel = true;
        }
      })
      // Show the widget
      .show({placeholder: '#browser'});
    });
    
    <div id="browser"></div>
    
  • Thank you Ferdinand, we were able to successfully update our widget to support Brava.

    You wouldn't have anything on properly picking up the OTDS authentication ticket, would you?

  • Well, I'm afraid I wouldn't :-)

    There comes no login page with the CS UI Widgets. (Just the fallback dialog you will get, if you don't provide OTCSTicker or OTDSTicket or other authentication header with the server connection parameters.) The idea is, that you log in to the portal, where the page with the Widgets resides - SAP, SharePoint, Oracle, Salesforce etc. You don't want to show the user an additional login. That's why you obtain the ticket for the Widgets (for the CS REST API) on the server side, when you generate the ASP/JSP or other page, where the widget is embedded. Usually, you get an OTDSTicket and render it on the page in a JavaScript variable, which will be used in the Widget initialization.

    If your integration page is a static HTML page, not generated by some server-side code, where you can hook in, there is no general OOTB SSO solution by OpenText for the Widgets. You will need some server-side generated page to help you get the ticket. For example, OpenText AGA deploys a request handler to the CS, which helps the integration page to obtain the ticket, if the customer logged in to Office 365. (The trust ACS - ADFS - OTDS - CS)

  • Hi,

    To your original question, you can use api/v1/ping (does not require authorization token) to get Info on current API version.

    Regards,

  • Unfortunately, the resource /api/v1/ping returns the same response in CS10, CS10.5 and CS16, including all their released updates so far. It cannot be used to detect the version of the CS REST API, or the availability of resources.

  • @Larry Nannery - Your question about getting OTCS authentication ticket, you can possibly use a WebReport which will get called by user and it will do SSO and you can then use WR tag [LL_REPTAG_OTCSTICKET /] to pass to your widget code. Hope that helps.

  • @Garg_Ravi nowadays OT's LLCookie [LL_REPTAG_OTCSTICKET /] is marked as HTTPOnly by default so does this methodology work still in that situation?

  • @Appu Nair - Yes it is HTTPOnly and we are loading the widget as iFrame URL which calls the Web report to generate OTCS ticket as SSO and then the Web Report loads the widget by passing the [LL_REPTAG_OTCSTICKET /] as parameter to the widget page. We had the similar challenge to authenticate user without presenting the login page and the Web report worked pretty well for us.