REST Authentication

Have an odd question...

We have a content server setup with authentication through OTDS. OTDS passes along groups from AD. And content server itself also has single sign on enabled.

I am in a developer AD group with a few other developers. Looking at OTDS, we are setup with the same permissions.... everything looks like it goes through groups, nothing set indiviudally.

The oddity comes in with calling the REST services.

Process is: Call into OTDS /authentication/credentials to get the ticket back. Pass that ticket into a api/v2/nodes/<id>/nodes REST call.

For me.... works just fine. For the other developers, the first step works great... the call into OTDS, get the ticket, good. But when they try to call the content server service passing in said ticket, they get a 401 error. Same code that works fine for me.

Any idea where to start digging to figure out what's wrong or different between my account and that of another dev? Already checked OTDS... looks fine as far as I can tell, and our accounts match as far as membership and permissions.

Thanks
Frank

Find more posts tagged with

Comments

appuGmail

After you are authenticated the authenticated user is checked on the permissions or ACL of the said node. If one were to guess you may have sys admin creds if you want to find out let the other developers try to go to the said node using the web GUI or if you do enhanced logging it may tell you the real error

Ciao, Appu

On May 1, 2017, at 7:11 AM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

eLink : REST Authentication
REST Authentication Posted byBeaty, FrankOn 05/01/2017 08:03 AM

HiHave an odd question...We have a content server setup with authentication through OTDS. OTDS passes along groups from AD. And content server itself also has single sign on enabled.I am in a developer AD group with a few other developers. Looking at OTDS, we are setup with the same permissions.... everything looks like it goes through groups, nothing set indiviudally.The oddity comes in with calling the REST services.Process is: Call into OTDS /authentication/credentials to get the ticket back. Pass that ticket into a api/v2/nodes/<id>/nodes REST call.For me.... works just fine. For the other developers, the first step works great... the call into OTDS, get the ticket, good. But when they try to call the content server service passing in said ticket, they get a 401 error. Same code that works fine for me. Any idea where to start digging to figure out what's wrong or different between my account and that of another dev? Already checked OTDS... looks fine as far as I can tell, and our accounts match as far as membership and permissions.Thanks
Frank
[To post a comment, use the normal reply function]
Forum: Content Web Services Forum
Content Server: Knowledge Center CS16

Beaty_Frank

--After you are authenticated the authenticated user is checked on the permissions or ACL of the said node. If one were to guess you may have sys admin creds if you want to find out let the other developers try to go to the said node using the web GUI or if you do enhanced logging it may tell you the real error

All devs have sysadmin at the moment. And everyone can go to and access the given node through the GUI. How do we turn on enhanced logging?

Thanks!
Frank

appuGmail

if you are doing something like

alert("CreateDoc: " + myTicket);

var myBody = { type: "144", parent_id: "24290", name: file.name };

formData = new FormData();

formData.append('body', JSON.stringify(myBody));

formData.append('file', file);

$(document).ready(function(){

var url = baseURL+'/api/v1/nodes';

That is basically a hit to the Livelink app at

http:<someserver>\<somevirtualdirectory><a script that ends in livelink.exe| llisapi.dll|cs.exe |livelink> etc

It goes on to say that whether you are doing REST or standard webaccess the access pattern is all going to be the same

So try getting into the "Enterprise Workspace" or "Personal Workspace" Many OT code incorrectly assumes that everybody's Enterprise Workspace is

api/v1/nodes/2000' so many world livelink systems have different than 2000

so my point is you need to just get on to a regular livelink URL and hit the node you are after and that goes for your friends also and see if webaccess

works for the node or location in question.

If one were to do enhanced debugging quoting my example

One would find the <someserver's>\config\opentext.ini

and just turn on Debug=2,wantLogs=True and wantlapilogs=true

each request hitting the server would indicate on its thread <nn>.out where <nn> is the thread number that serviced your request

more detailed info like <InArgs ,<OutArgs although I am not sure if wantlapilogs are good for REST one can see good info using

SOAP that way the Connect <nn>.out are verbose things happening at database,if you can look at that error gives a clue

Common mistakes that happen in setup

1)user profile has no public access and no permissions to access parts that are shown in a Get/post request

2)No real permission inheritance for example the user may have access to a inner depth folder but may not have a bread crumb trail stuff .You may have access to a folder with ID called " 12345678" who is a child of 2000/99999 and by some curious permission sets you may not have access to 99999.A Sysadmin has free reign .Many of these come to light by enhanced logging.

OTDS provides just basic services like vetting you and forwarding you back to the URL you really want which could be the applications real URL.

Also newer LL server's have much more simple debug enablement than trying to muck with opentext.ini check documentation.an old blog article sorry old may not help written some moons ago.

..... appnair appunair( Livelink Rocks )

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, May 1, 2017 at 8:32 AM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

[EXTERNAL] - Re REST Authentication Posted byBeaty, FrankOn 05/01/2017 09:28 AM

--After you are authenticated the authenticated user is checked on the permissions or ACL of the said node. If one were to guess you may have sys admin creds if you want to find out let the other developers try to go to the said node using the web GUI or if you do enhanced logging it may tell you the real error All devs have sysadmin at the moment. And everyone can go to and access the given node through the GUI. How do we turn on enhanced logging?Thanks!
Frank
[To post a comment, use the normal reply function]
Topic: REST Authentication
Forum: Content Web Services Forum
Content Server: Knowledge Center CS16

appuGmail

Oh and in many cases Chrome and other good browsers are able to give you very fine grained error messages.It does require you to be on a pretty recent REST API of OT though.

For e.g I tried adding a folder with the same name and used the Chrome debugger

I would try calling something in your friend developers personal workspace which he/she created to rule out permissions stuff

so do see if they offer you clues the chrome side will not catch anything that results in an "unhandled exception" at which point a livelink trace file will generate

..... appnair appunair( Livelink Rocks )

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, May 1, 2017 at 9:35 AM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

Re [EXTERNAL] - Re REST Authentication Posted byNair, KrishnankuttyOn 05/01/2017 10:33 AM

if you are doing something like alert("CreateDoc: " + myTicket);
var myBody = { type: "144", parent_id: "24290", name: file.name };
formData = new FormData();
formData.append('body', JSON.stringify(myBody));
formData.append('file', file);
$(document).ready(function(){
var url = baseURL+'/api/v1/nodes';

That is basically a hit to the Livelink app at

http:<someserver>\<somevirtualdirectory><a script that ends in livelink.exe| llisapi.dll|cs.exe |livelink> etc

It goes on to say that whether you are doing REST or standard webaccess the access pattern is all going to be the same

So try getting into the "Enterprise Workspace" or "Personal Workspace" Many OT code incorrectly assumes that everybody's Enterprise Workspace is

api/v1/nodes/2000' so many world livelink systems have different than 2000

so my point is you need to just get on to a regular livelink URL and hit the node you are after and that goes for your friends also and see if webaccess

works for the node or location in question.

If one were to do enhanced debugging quoting my example

One would find the <someserver's>\config\opentext.ini

and just turn on Debug=2,wantLogs=True and wantlapilogs=true

each request hitting the server would indicate on its thread <nn>.out where <nn> is the thread number that serviced your request

more detailed info like <InArgs ,<OutArgs although I am not sure if wantlapilogs are good for REST one can see good info using

SOAP that way the Connect <nn>.out are verbose things happening at database,if you can look at that error gives a clue

Common mistakes that happen in setup

1)user profile has no public access and no permissions to access parts that are shown in a Get/post request

OTDS provides just basic services like vetting you and forwarding you back to the URL you really want which could be the applications real URL.

Also newer LL server's have much more simple debug enablement than trying to muck with opentext.ini check documentation.an old blog article sorry old may not help written some moons ago.

..... appnair appunair( Livelink Rocks )

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, May 1, 2017 at 8:32 AM, eLink Entry: Content Web Services Forum <otdncontentwebservices971forum@elinkkc.opentext.com> wrote:

[EXTERNAL] - Re REST Authentication Posted byBeaty, FrankOn 05/01/2017 09:28 AM

--After you are authenticated the authenticated user is checked on the permissions or ACL of the said node. If one were to guess you may have sys admin creds if you want to find out let the other developers try to go to the said node using the web GUI or if you do enhanced logging it may tell you the real error All devs have sysadmin at the moment. And everyone can go to and access the given node through the GUI. How do we turn on enhanced logging?Thanks!
Frank
[To post a comment, use the normal reply function]
Topic: REST Authentication
Forum: Content Web Services Forum
Content Server: Knowledge Center CS16

[To post a comment, use the normal reply function]
Topic:	REST Authentication
Forum:	Content Web Services Forum
Content Server:	Knowledge Center CS16

REST Failure.jpeg

Khurram Shahzad

It may be relevant. If NLB is involved in token generation and authentication process, this could be relevant.

OTCS Ticket genereated from one node (of NLB) will not work with anohter another node (of same NLB) unless you update setting in "Cookie Authentication Infomation" under Server Security Parameters. By default, it will compare exact IP address. So token generated from one node will not be authentication against other node being two different IP addresses involved.

Regards,