401 Unauthorized error in mobile appworks

Could you please provide some more information?

Does this error occur when you deploy the app in AppWorks Gateway? Are you logged in as an administrator (default: "otag")?

Did you make changes to the app and set up OpenText AppWorks Gateway and OpenText Content Server as explained in this article?

We deployed CS Demo app in appworks client, we run it. For My profile it is working fine. But when we hit the Enterprise workspace it gives alert as 401 unauthorized ?
On Webaccess it is running properly but while deploying it on mobile it is showing some 401 error.Please tell me the way of deploying the CS demoapp on mobile with no error.

Are you sure the permissions on the Enterprise Workspace are correct?

Yes, we provide credentials as otag. Can you please provide steps to be followed for proper deployment of cs demo app in mobile ?

Are Content Server and AppWorks Gateway sharing the same OpenText Directory Services instance?

no,OTAG Server URL and Content Server URL are diffrent.We are passing local host(local system's ip) in OTAG Server URL
and a different Content server URL .

Yes, that is clear.

OpenText AppWorks Gateway relies on OpenText Directory Services (OTDS) for authentication. OpenText Content Server must use the same OpenText Directory Services instance.

Please refer to this section in the CSDemo article, which also mentions the required configuration of the OTAG Proxy Service. The OTAG Proxy Service is part of the free AppWorks Components, which can downloaded from here.

what should be the key to pass content.otagtoken -:otagtoken or OTCSTicket??
xhr.setRequestHeader( "otagtoken", content.otagtoken); OR
xhr.setRequestHeader( "OTCSTicket",content.otagtoken);

While hitting CS demo app in mobile we are getting logs on gateway is "2015-03-18 15:17:16.144 WARN com.opentext.otag.auth.IdentityService - Failed auth by otag: HTTP error: HTTP/1.1 401 Unauthorized". Can you please give solution for this logs ?

Hi Werner De Jong,

Currently, we do not have OTDS authentication setup on our instances. Will the app not work with the de-facto installation of CS with basic authentication? If not, then I believe this is what's causing the auth issue.

What we have not done or performed here is the reverse proxy and OTDS setup.

Is OTDS setup a necessity to run our custom apps? How do the Assignments app work then without OTDS?

Yes, that is a necessity if you want to run the app inside the AppWorks Client. The CS Demo App available from this site is a sample AppWorks App. It is designed to be run with AppWorks Gateway, accessing Content Server through the AppWorks Gateway (for which you need to configure the reverse proxy). It therefore requires OpenText Directory Services for authentication as described in the accompanying article.

Having said that, you can access the Content Server RESTful API directly, bypassing the AppWorks Gateway. Check out the Content Server REST API Quick Start Guide for more information.

Even connecting to the CS REST API directly (as you said, which is what we are currently trying to achieve), we still wouldn't be able to run this as well from within the AppWorks client that's hosted on the OTAG, correct?

I am 99% certain that that is correct, but I will double check.

Jason_Ibrahim

you should have no problem accessing the cs rest api from the app within the appworks client. just make sure you are using absolute paths (e.g. http://your-path) rather than relative paths and you should be fine.

Jason_Ibrahim

Ferdinand Prantl

Seeing these two statements:

xhr.setRequestHeader( “otagtoken”, content.otagtoken); OR 
xhr.setRequestHeader( “OTCSTicket”,content.otagtoken);

If they come from the AJAX call to the CS REST API, they are both wrong. If you want to use the CS REST API, you need an authorization token, which is accepted by the CS. I am not aware of any module, which would recognize otagtoken, but I am not sure if AppWorks provide some module for it. The value for the OTCSTicket should come from the CS REST API /api/v1/auth or from the LLCookie. Other headers I saw used are OTDSTicket or MYSAPSSO2, for example.

If your CS does not use the same OTDS as AppWorks, you will have no SSO provided by AppWorks and you'd have to provide the CS login on your own. As of Basic Authentication. The CS REST API is an API and does not send the authorization challenge to the browser; it just accepts the Authorization header if you send it. It is useful for API using tools, but there is no automated UI challenge in the browser. Speaking about the login dialog, once you decide to suffer it, you could call POST /api/v1/auth to get the value for the OTCSTicket header as well.

The natural way to connect to the CS REST API from AppWorks is using the OTDS ticket. You should get it somehow from AppWorks and set it to the OTDSTicket request header. I am not sure that window.otagtoken contains it.

Thank you Ferdinand.

So from the looks of it, it's pretty much possible to access the CS REST API from within the AppWorks client.
Yes, these calls are AJAX -> CS REST API and we are merely trying to replace the otagtoken variable value with the OTCSTicket value that we receive from POST /api/v1/auth separately in a prior method. We could change/rename the entire otagtoken variable to our will, but we are keeping the same name just for sanity sake.

However, the OTCSTicket hash value gets invalidated every time we try to access or call the very next CS REST API like /node/ right after the auth with a 401 Unauthorized Error.

Hardcoding a auth Token as the otagtoken

Setting headers

Ferdinand Prantl

You should not modify AppWorks auhorization token stored in window.otagtoken. If you don't share the OTDS for both AppWorks and CS you have to get your own token for the CS, on the server side or on the client side. Below is an example for the client side, but in the real solution you wold not hardcode the credentials there; you would have a dialog on the client side, or an impersonation on the server side, for example.

// specify the server connection
var cgiUrl = '//server/otcs/cs',
    credentials = {
      username: '...',
      password: '...'
    };

// requests an authentication ticket
function authenticate() {
  return $.post(cgiUrl + '/api/v1/auth', credentials, function (response) {
    window.otcsticket = response.ticket;
  });
}

// gets the personal volume data for the authenticated user
function getPersonalVolume() {
  return $.ajax({
    type: 'GET',
    url: cgiUrl + '/api/v1/volumes/142?expand=user',
    headers: {'otcsticket': window.otcsticket},
    dataType: 'json',
    success: function (response, status, jqxhr) {
      // refresh the ticket to avoid its expiration in future
      window.otcsticket = jqxhr.getResponseHeader('otcsticket')
    }
  }).then(function (response) {
    return response.data;
  });
}

// perform authentication
var auhenticated = authenticate();

// if authentication succeeded, show the personal volume name
auhenticated.then(function () {
  return getPersonalVolume().done(function (data) {
    alert(data.name);
  });
}).fail(function (jqxhr) {
  alert(jqxhr.status + ': ' + jqxhr.statusText);
});

Thanks for your very valuable responses (as always!), Ferdinand.

Thank you Ferdinand and Werner for your suggestions. This is exactly what we were looking for !