The Connection Object in smartUI

Setup of the Connection Object

smartUI does have a couple of interesting objects, but the actual documentation about them is not very clear. So lets take a look on the objects.

First, we’ll examine the connection object a little bit more in detail. The page context will follow in another post.

The connection object provides information about the content server to connect with. Normally, this object comes from the content server but has to be constructed manually when you use the index.html testing facility.

Lets take a look at a typical index.html with the connection object setup

Setup of the connection object

Remember, the widget will get everything beeing perfectly setup from the content server, but using the test faciliy, you have to mock up this.


  • url – the url which is the content server url in your mockup data
  • supportPath – where is your content server support directory
  • credentials – in case you want to log in, use this clause
  • session- when you want to ignore the ticketing etc, use ticket:”dummy”

Lets see what this object is doing:

(here the page is running and this is a screenshot from the debugger)

A debugging session with the connection object

We see, there is a connector object beeing the parent for the connection object. The connection object contains all parameter setups from the index.html, mainly the url and the session infos.

There is also an Authenticator in this connector object, which contains another copy of this connection object but also with the information, how the automatic re-login for a valid session ticked should be done. And of course, the type of Authenticator (here InteractiveCredentialsAuthenticator)

(Remember: The security token timeout will cancel your session (within typically 300 sec) if you do not a relogin).

This is the mechanism to avoid permanent logins. Take a look at the available authenticators to see the possibilities.

You can always refer the Connection Object to get the url of the server. This url os merged with the parameters in the Model URL function to build the final REST call.

A useful object. Normally we get it automatically from the server, only while testing with Mock-Up Data we need to setup this object manually.

Switch the smartUI SDK to Javascript ES6

When you start GRUNT, you will get errors on ES6 keywords, each LET will be flagged as error,

Have you ever wondered, why the SDK is not accepting JavaScript ES6? The wonderful new level of Javascript avoids for example the Variables Hoisting Effect by using LET instead of VAR. (Reduces the scope of the variables)

On the other hand, not all Browsers support ES6. So be aware that you may have to switch it back, if your browsers provide no support for ES6.

To change it:

  • open the node-modules folder in your project dir
  • scoll down until you find the module eslint-config-default . Edit the file .eslintrc in a tect editor (screenshots are from WebStorm IDE)
eslint config default in node_modules

in this file, you’ll see that the file off.js is used for configuration. Open this file in a text editor.

The file off.js

Here you see, that es6 is set to false (Yellow Arrow). Change this to true and save the file (maybe under another name. In this case, correct the require command to reflect the new name).

So now the GRUNT-file is producing no problems when it encouters a LET.

But be aware: If your bropwsers lack some support for es6, you must switch back to ES5.

The smartUI Page Context

•The simplest context in smartUI is the Page Context, which can include and fetch models and collections, but does not provide any other functionality. If you use it with widgets, which expect changes based on their context-changing models, you will have to handle these changes yourself.

You can use the page context like this

 require(['csui/lib/jquery', '../page.context', 'csui/utils/contexts/factories/connector',
       'csui/utils/contexts/factories/user', './page.context.mock'
     ], function ($, PageContext, ConnectorFactory, UserModelFactory, PageContextMock) {
       var contentElement = $('body'),
           context = new PageContext(),
           connector = context.getObject(ConnectorFactory),
           currentUser = context.getModel(UserModelFactory);
           .text('Connected to the server ' + connector.connection.url)
           .done(function () {
                 .text('Current user is ' + currentUser.get('name'))

This results in

New Permissions Explorer in smartUI

Have you seen the new permissions explorer in smartUI? Open up the permissions on an object and you’ll see the new selection.

Permission Selection
Permission Selection
The Permissions Explorer
The Permissions Explorer

The permissions explorer is opened with a click on the “Permissions Explorer” Button on the upper right.

Inside the Permissions Explorer
Inside the Permissions Explorer

This will give you the option to edit all permissions of the objects in this folder at once.

New smartUI Training for Content Server 16.2.8

The actual Content Server release 16.2.8 brought a lot of improvements to the smartUI SDK, for example the xECM and the connected Workspaces Widgets are nowadays part of the SDK.

Also a lot of of people were interested in smartUI, not only Developers.

So we introduced an updated 5 days training to reflect the changes of 16.2.8 and a 2 days training to provide an overview of the SDK. Naturally, a 5 days training gives more information and also more exercises than a 2 days training, but this 2 days training can provide a good overview for Team Leaders and technical Managers.

For those with little time, there is also a 1 day training giving you a more compact overview for technical Managers and technical Evangelists. The one day training is not recommended for Developers. This training was held at the Enterprise World in Vienna 2019.

Whats new in the trainings?

New in the basic training

The Chapter 6 (SDK Intro) (5 days training Basic)

  • 6.1 Introduction
  • 6.2 Installing the SDK. Different Installations in 16.2.4 and 16.2.8. (NEW)
  • 6.3 Building the Demo Widget
  • 6.4 CSS Style Overrides Binf (OpenText Bootstrap Version)
  • 6.5 General Overview
    • General Overview
    • General Architecture, Coding Guidelines
    • Logging, Internationalization and Localization
  • 6.6 Content of the SDK
  • 6.7 Routing Preview (see adv. Training for a more detailed discussion)
  • 6.8 New Command
  • 6.9 Custom Column
  • 6.10 Metadata
  • 6.11 Define a new Nodetype
  • 6.12 Create a Widget
  • 6.13 Base Widgets. Detailed info’s on base widgets.
    • Favorites
    • Recently Accessed
    • MyAssignments
    • Shortcut
    • Shortcuts
    • Metadata
    • NodesTable
    • DocumentOverview
    • Search Results (NEW)
    • Permissions (NEW)
    • Html.editor (NEW)
    • Navigation Header (NEW)
  • 6.14 Controls and Contexts
    • Controls
      • Node Picker
      • Modal Alert
      • File Open
      • Perspectives: Grid, Single, Left-Center-Right, Tabbed, Tabbed-Flow
      • Tile
      • ListView
      • ListItem
      • Signin
      • UserPicker
      • Breadcrumps
      • Checkbox
      • Dialog
      • Disclosure (NEW)
      • Error (NEW)
      • Form (NEW)
      • Globalmessage (NEW)
      • Grid (NEW)
      • Zip&Download (NEW)
      • Integration Folder Browser
      • Integration Target Picker
    • Contexts
      • Detached objects
      • Permanent objects
      • Temporary objects
      • Page Context
      • Browsing Context
      • Perspective Context
      • Portal Context
  • 6.15 Models and Factories
    • NodeModel
    • Other Models
    • Factories
      • Fetchable Factory
      • Configurable Factory

A new Chapter 12 discusses the strategys needed to “widgedize” an existing legacy g module and to add things to an existing widget

The strange word “to widgedize” stands for “Build a widget for a legacy module not already supporting widgets”. The Strategies on amending a Module by adding a widget and on adding additional functionality inside an existing widget are discussed.


  • Moving from a legacy gui module to a smartUI module
    • Examine a legacy module and rebuild a smartUI widget (here only on the client side)
    • As an example, the barcode widget
  • Add a functionality in an existing widget
    • Add an email functionality in the Connected Workspaces Team Widget.
    • Usable from inside the Widget
    • As an example the new team widget with email Support

New in the advanced training

The advanced training will eventually grow more and more to cover the new widgets and controls coming in future releases.

Chapter 1: Extended SDK Parts

  • Additional Widgets
    • Webreports
      • NodesListReportView
      • TilereportView
      • FilteredCountChartView
      • Carousel Widget View
      • parameter.prompt.form (NEW)
      • (NEW)
      • status.screen (NEW)
      • open.webreport.js (action to show the Parameters form) (NEW)
  • binf-Datepicker
    • Using the build in datepicker
  • binf-switch
    • Using the binf-switch to turn checkboxes and radio buttons into switches
  • Workflow
    • Workflow Components
    • Workflow in smartUI including Workflow Status (new in 16.2.4)
    • Starting Workflows
    • URL Routes
    • Workitem Model
    • Workitem Actions
    • Workitem Extension
    • Writing Workflow Extensions
    • REST API Support for Workflows
  • Connected Workspaces
    • Configurationvolume (NEW)
    • Header (NEW)
  • Extended ECM
    • xECM: Office365 Groups (NEW)
    • xECM: Header Widget with Business Object Infos (NEW)
    • xECM: Snapshot of current document Attachments (NEW)
    • xECM: Dossier View Widget (NEW)
    • Event Action Center (NEW)
  • Widgets not part of the SDK
    • Mobile Scanning
    • Discussion Widget
    • Engineering Doc Management: Search
    • MyShares

The chapter 3 has also been amended

  • Tips and Tricks (Work in Progress- List can change)
    • Add a OTDS Ticket already in the browser to the connection object
    • Re-using a OTDS Ticket as LLCookie
    • Checking the paths in the test/index.html
    • Adding non CSUI supported jQuery functions in a view
    • Add additional jQuery Libraries
    • Adding Controls to a widget (NEW)
    • CKEDITOR 4 (NEW)
      • Intro (NEW)
      • JQuery Non SDK example (NEW)
      • Usage in the SDK (NEW)
    • Handlebars advanced
      • Handlebars QuickStart
      • Expressions
      • Helpers
      • Helpers with html output
      • Helpers with Hash Object
      • The Helper fn property
      • The helper inverse property
      • Partials
      • Helpers in the SDK
      • 188 Handlebar Helpers
    • LESS advanced
      • LESS installation
      • Using LESS variables
      • Using Mixins in LESS
      • Parametric Mixins
      • Guarded Mixins
    • Accessibility in Bootstrap. Screen reader support and what’s to change in the SDK to support screen readers for visual impaired users.
      • What is Accessibility
      • Kinds of Disabilities
      • Accessibility and the law
      • WAI-ARIA
      • PayPal Bootstrap Accessibility Plugin
      • Web Experience Toolkit WET
      • Other resources
    • Best Practices in smartUI development
      • Pre-Development Steps
      • Preparation Steps
      • Development Steps
      • Integration Steps
      • Documentation Steps
  • Development Infrastructure for security aware Organizations (NEW)
    • Recommendations what’s to do if the reloading of npm modules during the creation of a widget is not wanted (NEW)

The agendas are available as pdf here

  • 2 day Agenda the training with more details and more exercises

Improved smartUI Webreport Usability

The usability of Webreports in smartUI has been improved. Now, you can, after starting a Webreport, edit the parameters of that report and receive feedbacks from the running Webreport. This makes a lot of fun!

Lets see, how this is done.

First a widget can be used to list all data.

Click on a Webreport to start it

Then a Parameter Window opens. The Webreport can be startet by pressing the button “Run Webreport”

Webreport Parameters can be edited
Webreport Parameters can be edited

A feedback can be given from the Webreport like this

Running webreports can give Feedbacks to SmartUI
Running webreports can give Feedbacks to SmartUI

The shows a Smart UI table based on the output of WebReports data. The WebReport used by this widget must be based on either the widget_table_report_process_data_in_webreport or widget_table_report_process_data_in_datasource default reportviews which use the INSERTJSON @TABLEREPORT directive.

   // Create the data managing context
      var context = new PageContext(),
      sampleTableReportView = new TableReportView({
          context: context,
          data: {
            id: 24024,
            sortBy: "SubType",
            SortOrder: "ASC",
            columnsWithSearch: "SubType",
            titleBarIcon: 'mime_audio',
            title: 'Sample WebReports Table',
            header: true,
            swrLaunchCell: {
                id: 12345,
                iconClass: 'my-icon-class',
                hoverText: 'Some hover text for my icon.'
 parameters: [
                    name: 'myparm1',
                    value: 'val1'
                    name: 'myparm2',
                    value: 'val2'
      // Create helpers to show the views on the page
      region = new Marionette.Region({
        el: "#content"

      // Show the views on the page;

      // Fetch the WebReport output from the server to populate the tile with

The parameter window can be implemented like this (the xxxxxx is the node number for the webreport)

  var promptView,
        contentRegion = new Marionette.Region({el: "#content"}),
        pageContext = new PageContext(),
        currentNode = pageContext.getModel(NodeModelFactory, {attributes: {id: xxxxxx}}),
        runWRModel = pageContext.getModel(PromptModelFactory, {
            attributes: {
                node: currentNode
        runWRController = new RunWRController();
            .done(function () {

                // We've got the page context, now get the runWRModel to see if there are parameters:
                    node: currentNode,
                    context: pageContext
                }).done( function(){

                    // Build the prompt view and show it:
                    promptView = new PromptView({
                        context: pageContext,
                        model: currentNode,
                        promptModel: runWRController.runWRPreModel,
                        showBackIcon: false


A feedback is implemented by the status.screen control.

  require(['csui/lib/underscore', 'csui/lib/marionette', 'csui/utils/contexts/page/page.context',  'csui/utils/contexts/factories/connector',
  ], function (_, Marionette, PageContext, ConnectorFactory, GlobalMessage, StatusScreenView, WebReportRunModelPre, WebReportRunModel, WRMock) {

  var statusView,
  context = new PageContext(),
  connector = context.getObject(ConnectorFactory),
  region = new Marionette.Region({el: "#webreport-status-screen-demo"}),
  attributes = { id: xxxxxx },
  options = { connector: connector },
  WRRunPreModel = new WebReportRunModelPre(attributes, options),
  WRRunModel = new WebReportRunModel(attributes, options);
  WRMock.enable(); // Mockup for local tests
  .done( function(){

  .done( function(){
statusView = new StatusScreenView({
  destinationModel: WRRunPreModel.destinationModel,
  executeModel: WRRunModel});;


Working with WebReports and SmartUI now makes a lot of fun!

Technical Training “How to program a Widget in the new Content Server GUI” with the CSUI SDK

Hi folks

Beeing Content Server Trainer, I was asked to provide a training “How to program a Widget for the new Content Server GUI” to several customers. This is about the content of such a training and the reason why such a training is technically really advanced.

CSUI SDK introduces a shift in paradigma, the server is no longer providing the GUI, all is done by a Javascript Application at the client side.

Basic Training (newest version 1.005 from Feb/2018)

The basic training is very compact and lasts 5 days.

First, lets take a look on the components:

As a prerequisite, a firm knowledge of CSIDE, How to build a module, the Node Structure and whats to do with Content server Nodes is necessary.

At the end of the training, you’ll have a working knowledge of:

  1. Content Server Perspectives. What are they and how you can use them to provide a user specific interface.
  2. Content Server REST. This is the only possibility for the client to communicate with the server, so its mandantory to know the REST interface from the application point of vue. And, as REST can be very slow due to unneccesary data, its also mandantory to know, how to add REST services to the Content Server to get the data you want in the fastest way.
  3. Javascript. There are Javascript Patterns, which are used heavily in the SDK. If “Javascript Object Inheritance”, “Currying/Schoenfinkelizing”, “Decorators” etc are weird words for you, this chapter is the right chapter for you.
  4. Next is the infrastructural world of the sdk.

    CSUI Components
    The CSUI Components

    There are several components, which must be understood prior to build a Widget.

    1. node.js is the base Javascript system for our development
    2. grunt.js is a Javascript task runner, which we use to build, test and debug our widget
    3. yeoman is a scaffolding system, which will be used by a Opentext extension to initialize the development folder. It also creates the skeleton of a Content Server module, which is used as a “Carrier” for our Widget(s)
    4. backbone.js is the base framework to be used
    5. marionette.js is an extension to backbone.js, making Views easier.
    6. handlebars.js is the html templating framework used in the sdk
    7. require.js is the javascript module loader to be used
    8. bootstrap.js/binf.js is originally the public domain CSS/JS framework from Twitter for the appearance of the Widget. Binf is the Opentext variant, allowing to override CSS without negative effects
  5. Next is the SDK itself. Due to time restrictions, in the base training are only the base functions, the advanced training covers the other aspects. It contains
    1. Installing the SDK
    2. Building the Demo Widget
    3. CSS Style Overrides binf
    4. General Overview of the SDK
    5. Content of the SDK
    6. Routing (Preview of the Advanced Training)
    7. New Commands
    8. Custom Columns
    9. Metadata
    10. Define a new NodeType
    11. Create a Widget
    12. Base Widgets
    13. Controls
    14. Models
  6. Mockup and Test Data. How to setup mockup REST data. How to build test facilities in the SDK
  7. Anatomy of the Hello Widget. A walktrough through this widget
  8. Anatomy of the MyAssignment Widget
  9. Add another Widget to the Content Server. Change the Hello Widget and add additional fields
  10. Build a Custom Widget to be used as Client with a custom REST service. Here, a custom widget is build, which uses an extended version of the custom REST service from Part 2.
  11. If time allows: Some Tips and Tricks from a “Work-in-Progress” Widget


Advanced Training (Version 1.005 Feb/2018)

OK, thats the basic training. There are a lot of additional things inside the SDK, but to understand these, there must be a couple of weeks with practical experience in between. The advanced part has beed remodelled to include a couple of interesting things.  The advanced part contains:

  1. Chapter 1 Extended SDK Parts
    1. Additional Widgets
      1. NodesListReportView
      2. TilereportView
      3. FilteredCountChartView
      4. Carousel Widget View
      5. Userwidget eSocial
      6. ActivityFeedWidgetView
      7. ActivityFeedContent
      8. ChatWidget
    2. Datepicker
    3. switch
    4. Workflow (new in Content Server 16.2)
      1. Workflow Components
      2. Workflow in smartUI
      3. Starting Workflows
      4. URL Routes
      5. Workitem Actions
      6. Workitem Extension
      7. Writing Workflow Extensions
    5. New REST API Support (16.2) for Workflows
    6. Widgets not part of the SDK
      1. Mobile Scanning
      2. xECM: Header Widget with Business Object Infos
      3. xECM: Snapshot of current document Attachments
      4. xECM: Dossier View Widget
      5. Engineering Doc Management: Search
      6. xECM: Office365 Groups
  2. Chapter 2 Extended SDK Features
    1. Build Language Packs for Internationalization
    2. Commands
      1. Implementation and Inheritance from “CommandModel”
      2. Best Practices
      3. Using Commands
    3. Custom URL Router. Routing, adding custom Routers. Using Routers as Navigation.
    4. Behaviours. What are Behaviours?
      1. DefaultActionBehaviour
      2. BlockingBehaviour
      3. ExpandingBehaviour
      4. InfiniteScrollingBehaviour
      5. PerfectScrollingBehaviour
      6. PageLeavingBehaviour
    5. Mixins. What are Mixins? All available Mixins.
    6. Browsable Support for Collections. Using the “Browsable” support for Model-Collections.
  3. Chapter 3 Additional Things to consider
    1. Tips and Tricks (Work in Progress- List can change)
      1. Add a OTDS Ticket already in the browser to the connection object
      2. Re-using a OTDS Ticket as LLCookie
      3. Checking the paths in the test/index.html
      4. Using Helpers for supporting a select box with Handlebars
      5. Adding non CSUI supported JQuery functions in a view
    2. Handlebars advanced. A deeper look into Handlebars
    3. LESS advanced. A deepter look into LESS, the CSS language used in Bootstrap
    4. Accessibility in Bootstrap. What can be done to add support for screenreades etc to Bootstrap/Binf? Whats to avoid? Which tools are available
    5. Best Practices in Development


As you can see, there is a lot of stuff. The basic training last 5 days, the advanced training 2. But on the other side, you’ll get happy users with your new Widgets.

And that’s all what counts.


  • “JavaScript Application Design “as a general introduction (covering Grunt)
  • Stoyanow’s JavaScript patterns
  • Flanagan’s “JavaScript: The Definitive Guide”
  • Crockfords “Javascript The good Parts”
  • Flanagans “JavaScript Pocket Reference”
  • Spurlock: Bootstrap Responsive Web Development
  • Syed Fazle Rahman: Jump Start Bootstrap: Get Up to Speed With Bootstrap in a Weekend
  • Alan Forbes: The Joy of Bootstrap: A smarter way to learn the world’s most popular web framework
  • Greg Franko: Instant Dependency Management with RequireJS How-to
  • David Sulc: Structuring Backbone Code with RequireJS and Marionette Modules
  • Developing Backbone.js Applications Adnan Osmani
  • js Patterns and Best Practices Swarnendu De
  • js Cookbook Vadim Mirgorod
  • js Blueprints Andrew Burgess


  • Getting Started with Backbone Marionette Raymundo Armendariz, Arturo Soto
  • Marionette.js: A Gentle Introduction David Sulc
  • Marionette.js: A Serious Progression David Sulc
Mockjax and Jasmine
  • js Cookbook Vadim Mirgorod Chapter 8
  • KnockoutJS Essentials Jorge Ferrando
  • JavaScript Testing with Jasmine Eva Hahn


Content Server Trainings
  • 4-0140 Content Server IDE (CSIDE) Fundamentals
  • 971-301 Livelink ECM Enterprise Server Workflow Customization Fundamentals
  • 03-0117/8 Webreports Design



A new SDK in Town: Content Server SmartUI SDK – First glimpse

Did you ever wonder, how to create new widgets or forms for the new SmartUI of the content server? The new SmartUI is responsive and can be used on mobile devices.


If you want to add new widgets or modify things, there is a new SDK on the knowledge center, which can be found here:

This are the components:

  • CSUI SDK Intro.pptx
    this is a powerpoint presentation on the SDK.
  • (1.7MB)
    this is the documentation as stand alone.
  • (53.5 MB)
    this is the sdk itself. It contains a copy of the documentation.
  • (122 kb)
    this is a kit to provide branded css files, which will be used instead of the original ones.
  • MB)
    this is a generator, which will be used to setup an empty development project.


The basic requirement is the installation of node.js at your CSIDE machine.  You should be familiar with the REST API and Grunt to use the SDK.

The workflow is

  1. Generate an empty project on the harddisc
  2. Install all prerequisites in node.js (npm, grunt-cli)
  3. Modify the example according to your needs
  4. Import the module in out-module of your project into CSIDE
  5. Copy the widgets etc into your support folder
  6. Create the module in CSIDE and install it

The installed new Widget

Then you should see the example widget under the name of your module in the perspective manager.

Watch for upcoming posts on this exciting new Content Server technology.

Upload a File to Content Server using REST and Javascript

This is an example how to upload a file using JavaScript and REST.

This example uploads the file c:\test.txt with the name of “MyFile123” under the folder with the node id 485336. This snipped relies on a previous login. The subtype of the file to be uploaded is “document” (144). The authorization token is saved under the variable name of “otcsticket”.

This example does not consider any categories (mantadory or not). We’ll discuss this in a later post.

6 Steps:

  1. Declare all variables needed. This is done by defining the array bodyData. At least there must be the subtpe, the parent_id, the name and the local file name.
  2. Fire an AJAX request to the URL, where your content server is, Use “api/v1/nodes” as REST command.
  3. Put the authorization ticket in the header field
  4. Put the bodyData in the data field
  5. Set the Mime Type to “application/x-www-form-urlencoded”
  6. If the request is done, process the “success” or the “failure” clauses

Put some nice HTML around it, add the authorization code and then you are done.

(At least for this example. Normally, you should provide some name check for the node name)

function upload() {
  var bodyData = {
        type: 144,
        parent_id: 485336,
        name: "Myfile123",
        file: "c:\\test.txt"
      formData = new FormData();
  formData.append( "body", JSON.stringify( bodyData ) );

  formData.append( "file", "c:\\test.txt" );
  return $.ajax( {
    type: "POST",
    url: "http://[yourserver/yourcs/cs.exe/api/v1/nodes",
    data: bodyData,
    headers: { otcsticket: otcsticket },
    beforeSend: function( xhr ) {    
    xhr.overrideMimeType( "application/x-www-form-urlencoded" )
  } ).then( function ( response ) {
  }, function ( jqxhr ) {
  } );


Authentication (1/3) How to authenticate against the Content Server in REST/Javascript

This is the first post on a series about authentication against the content server. The first post explains the authentication from a html page with Javascript and JQuery using REST

The REST API can be used to perfom things on the Content Server from nearly every thinkable language. Here is the example how to do a login from Javascript.

Replace [yourserver] with the DNS name of your Content Server, replace [yourCSInstance] with your CS instance and the cgi.

A valid URL would be for example

for the Authentication request.

  var otcsticket = "";
  * This function needs to be run first to authenticate the user against Content Server.
  function authenticate() {
  // Set up the ajax request
  // Authenticate is a POST
  type: "POST",
  url: "http://[yourserver]/[yourCSInstance]/api/v1/auth",
  data: { username: [username], password: [password] },
  beforeSend: function( xhr ) {
  // Set the correct MimeType for the request.
  xhr.overrideMimeType( "application/x-www-form-urlencoded" )
  }).done( function( data ) {

var val = JSON.parse( data );
  alert( "setting otcsticket to: " + val[ "ticket" ] );
  // Store the ticket for later use.
  otcsticket = val[ "ticket" ];


To authenticate, a $.ajax call is used. The REST call to do this is “/api/v1/auth”. The data must contain a valid username and a valid password for this user.

If the call is finished, then the JSON array (in the response) must be parsed for the key “ticket”. The value is the authentication token which should be stored somewhere for further use. Normally, the name otcsticket is used for this.

The token should be send as a header in any request, like in this example:

$.ajax( {
  type: "POST",
  url: "[yourURL]/api/v1/nodes",
  data: bodyData,
  headers: { otcsticket: otcsticket },
  beforeSend: function( xhr ) {
  // Set the correct MimeType for the request.
  xhr.overrideMimeType( "application/x-www-form-urlencoded" )
  } ).then( function ( response ) {
  }, function ( jqxhr ) {
  } );

(This is a call to upload a file, for the complete example on uploading files with REST see the posts in January 2017)