Status: Open
Status: Answered
Status: Closed
Status: Duplicate

Content Server REST API

Posted Aug 15 by Eben de Roock.
Updated Aug 15.


I'm trying to access Content Server's REST API via the OTAG Reverse Proxy Service, but I get prompted for credentials when a request is made to the CS REST API. Supplying credentials does not work and keeps on prompting for credentials. We are using NTLM authentication on Content Server, when using a REST Client I have no issues calling the Content Server REST API.

Content Server's threads logs contains the following:
LibOTSecBuiltins: Decryption failed - data_len: 3 crypt_len: 0
Check HTTP Referer has been disabled for the RestAPI since it does not make sense.
Dispatcher error: Authentication Required

Thanks in advanced


I got it working by sending the request directly to Content Server rather than using the Reverse Proxy. I can now supply Content Server with a username and password and receive a authentication token, I can then use the provided token to do other requests.

I have another issue now, I'm trying to authenticate the user without the user providing his/her credentials, I trying to follow the Tempo Box route by using a redirection request handler in Content Server. OpenText generate a token that is sent to Tempo Box to authenticate the user. The token I'm given by Content Server does not work for my web app and I keep getting the credentials prompt. Any ideas where I might be going wrong? I copied the code from the OTSync module for my redirection request handler


3 Answers

BEST ANSWER: As chosen by the author.

Does the OTAG reverse proxy support proxying NTLM authentication?

If it does, it should work from the browser or a client capable of NTLM authentication, but other tools talking to the REST API would not be so lucky. As long as you use none, it is no problem, but later you might need to define an alternative virtual directory for the CS CGI executable/ISAPI filter, with IWA off and anonymous access on, which you would use for the REST API access. You would avoid the NTLM authentication, which the REST API doesn't support anyway. (You can set any header accepted by a CS login callback, like the usual OTCSTicket or OTDSTicket, or Basic Authentication without the request-response challenge.)

What token did you get? If it is LLCookie, use it for the OTCSTicket header. If it is OTDSTicket, set it in the OTDSTicket header. Have look at other post how to do it.

BEST ANSWER: As chosen by the author.

Thanks Ferdinand, my issue ended up being that Content Server encodes the LLCookie before passing it as a variable, so when I submit my form to AppWorks for authenticaiton it ends up being encoded twice and has to be decoded twice.

BEST ANSWER: As chosen by the author.

Thanks for letting us know! Actually, I was bitten by this recently when using the LLCookie from document.cookie

var llcookie = $.cookie('LLCookie'), //
    otcsticket = llcookie && decodeURIComponent(llcookie);

 You have subscribed and will receive email notifications of updates to this topic. To unsubscribe, uncheck the checkbox.


Related categories

Related tags

Your answer

To leave an answer, please sign in.