This is less of a question and more a series of observations. When I was first exposed to the ReST API, I thought it might be a good option for designing UI components to be used within Content Server. The main problem is authenticating between them. That is, if you are logged into the CS UI, you are not logged into the ReST API. In theory, if you have the LLCookie for one, you have the authentication for the other. I verified this by taking the HTTP_COOKIE value from my UI browse request in CS Builder, performed a Web.Escape on the string, then pasted the escaped string into my otcsheader in my Advanced REST Client for Chrome. That worked!
Theoretically, a REST client developer might do a hybrid solution. After getting the authentication token, perhaps encrypting it some more and putting it in a regular cookie and customizing the standard ExecuteWithLogin on the Request handler object to grab that, decrypt it, and store it in LLCookie going forward. That is, the ReST client is the gatekeeper of authentication, and CS UI is the slave. It strikes me that this would be a more invasive customization than just doing what you need as a module containing web-lingos, and by exposing the authentication token, even encrypted, adds on to your security woes.
So, it appears that as cool as the ReST API is (I've been having a lot of fun playing with it, BTW), for folks who use the standard UI, offer them changes using Web Reports, ActiveViews, Appearances, or good old-fashioned Oscript :) If I'm talking complete smack, I hope someone points it out.
You write about the authentication problem only. I see it exactly the other way round. In comparison with SAP, Oracle or SharePoint portals, the CS as an application portal has a huge benefit - you log in to the CS and you get the ticket for the REST API "automatically". No problem with a second login and configuring SSO. In other portals you'd have to build the trust with the CS somehow first to enable SSO, or implement impersonation, or suffer the second login to the CS.
You need nothing so complicated as you described. You can have the OTCSTicket (LLCookie) available on the web page as
window.otcsticket, for example, as noted here. Now you'd have do it by your WebLingo, which is surprisingly easy - one line of code. but I expect it available on every page generated by some common WebLingo in the future.
Generally, I agree that there are other tools better for the CS UI customization, which you listed. The classical CS UI pages are based on the server-side page generation and there are extensibility point available when following this scenario. When you create an extension working as a browser application talking to the server by REST API asynchronously when necessary, it may not fit with the rest of the functionality. I don't say that it should be avoided; I believe that there are extensions (facets) where REST API has advantage. You should have a look what you want to achieve and sometimes use the server-side CS UI extension hooks or buy ActiveViews, which leverages them, but sometimes use jQuery + REST API, if it benefits the goal.
If you already have an appearance (WebLingo) with jQuery, you can add this line there:
Supported by your utility function like the following one. A function like this should be added to a core ospace; RESTAPI, CSUI or WEBLL. More about this below.
object MYOSPACE::Utils string function GetOTCSTicketForRequestHandler(Object requestHandler) // As soon as the REST API uses its own ticket, this will change return requestHandler.fCookieData(requestHandler.fCookieName) end end
Again, the reason why the REST API may not be the universal way to extend the classical CS UI is not the authentication, but the different nature of web applications based on server generated pages and web applications running in the web browser using REST APIs.
Quick question on your response: I had no idea that Oscript could be exposed in an Appearance (I'm talking core Content Server Appearances, not custom web-lingo), or are you suggesting an edit to one of the weblingo files used by apeparances?
I might've confused in with the appearances, which use the technique of injecting a header component on the pages, but I'm not sure if you can use WebLingo in there.
This would be the way how to do it in your module: orphan WEBNODE:HTMLComponents and point it to your WebLingo file. Set features of the orphan similarly to APPEARANCES:Appearance Header Component. The HTML fragment generated by the WebLingo will appear on every page, where the header is enabled in the GUI components of the request handler.
Ha! I thought orphaning would come into this sooner or later :)
You need to sign in before voting.
You need to sign in before voting.