CS HttpOnly Setting and REST API

Ed Davis

We migrated our Premise CS 16.2 Environment to MS AZURE CS 21.3. During our migration we ran into some problems with REST API calls within some complex HTML forms. We found out after investigation that the HttpOnly setting was set on our new environment and not in our old environment. This enabled the HTML form to retrieve the LLCookie via a Javascript call. We do this because we support SSO and do not want the user to provide credentials once he/she is logged in. In our forms that are built using Web Reports, we can do the same with [LL_REPTAG_OTCSTICKET QUOTE /] within the Ajax Call. Unfortunately, changing this HTML form which has a lot of relative references to .js and .css libs would be very tedious and undesirable. In the interim, we have disabled the HttpOnly setting and flagged the issue as a medium security threat which we are trying to deal with.

My Question is whether anyone would have some suggestions or guidance.

I have thought of a couple of options:

1. The HTML form is called from a Web Report via a formatted GRID with an edit button for each row (record). I could retrieve the OTCS/OTDS Ticket from the WR and pass it as a parameter to the HTML form. This would be relatively easy, but I wonder about passing the security token, but this would be encrypted via SSL/TLS.
2. Create a Web Report with one line[LL_WEBREPORT_EXCLUDEHTML /][LL_REPTAG_OTCSTICKET QUOTE /] which will have the token of the user who runs it. That would be great, but I don't know if you can run a WR from a HTML page and retrieve the results.

Any input would be appreciated.

Ed

Appu Nair

There's always going to be a "chicken & egg" thing. What I think you would benefit is basically "emulate" what the smartui page does which is essentially writing the credential to a webpage that one doesn't see ,the smartui page then retrieves this from the html page and starts calling rest api request with it .Perhaps if you look in a dev server the app.html which is the loading point of any smartui you will understand its mechanism. theres a onload page that usually hits this endpoint rest/authentication/headers .Thi sis the standard mechanism of rest to retrieve a SSO token so the output of this is used to call subsequent. It will take some digging . I think @Ferdinand Prantl actually has some articles written that may be more correct than what I said .