We're just getting started with OTCS and want to see what the endpoint is returning. With all of our other APIs, when the user has appropriate permissions to a location, they could just open an endpoint in the browser to preview the json. When I attempt this with Content Server, it prompts me to auth/login 3 times in a row and then fails with {"error":"Authentication Required"}. The constructed URL I'm trying with looks something like this:http://opentext.dev.mysite.com/otcs/llisapi.dll/api/v1/nodes/100772129/nodes Goal will be to consume document details and metadata from CS search but we're just starting with a known node to test our API calls.
If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.
REST will only give you output if the Header for authentication is specified Is that what you are talking about? having Content server in a network and another app in the same network and thinking REST calls can seamlessly pass between the two is prevented by OT for obvious reasons.We all use POSTMAN get a token and submit it with other REST calls as explained in developer.opentext.com
see also recent posts containing how to pass LLCookie to REST queries,also LLCookie will only be present in your browser if that browser has already authenticated first with content server
Thanks, Appu, that is different behavior from the other REST APiI we are currently working with. We'll work with your suggestions and see where that gets us.
@Mr_Moose here's an official thing https://knowledge.opentext.com/knowledge/llisapi.dll/kcs/kbarticle/view/KB12765740
Also how companies use SSO in environments is something like this 1. CS Webserver should not be IWA.REST will not work against IWA. If you want REST support but others want IWA to consider running some servers on IWA and others anonymous. 2. A typical call into a livelink URL will turn into an auth request to OTDS,you get a ticket 3. This OTDS Ticket can be used for REST, if the caller was a browser to livelink then for purposes of not overloading OTDS the "LLCookie" can be passed into the livelink code. Recently somewhere here I posted some code that shows how I take the "LLCookie" in a WR(an Object in LL) and call REST. In latest versions, the LlCookie is given to you in a WR tag so you don't have to write a JS routine. 4. If your app is a stand-alone app then you should use the authentication service of OTDS to get a "Token" and then you should use that in your Livelink header like the examples in postman.
Note the REST api also supports Basic Authentication. When experimenting you can simply plug a username&password into the configuration of your favorite REST client and then forget OTDS even exists. Just a tip that might be handy.
You will find more information in Content Server REST API - Quick Start Guide.
