Edit link in CSUI Widget opens a page that causes a need for authentication

I have embedded the FolderBrowserWidget in a custom application that authenticates the widget with CS using an OTDS Ticket in the connector. Here is a code snippet showing how it gets instantiated and started. (This is an Angular TypeScript application)

const otdsToken: string = this.userLocalStorageService.getOtdsToken();

csui.onReady(() => {
const connector = new csui.util.Connector({
connection: {
url: this.configurationService.ContentServerUrlWithApiUrl,
supportPath: this.configurationService.ContentServerSupportPath,
// AuthenticationHeaders: OTDSTicket is a token retrieved from OTDS.
authenticationHeaders: {
OTDSTicket: otdsToken
}
},
start: this.startNode
});

this.folderBrowser = new csui.widget.FolderBrowserWidget({
connector: connector,
start: { id: this.startNodeId },
breadcrumb: {
stop: { id: this.startNodeId },
limit: 1
},
facetPanel: {
expandFirstFacet: true
},
backButton: true,
menuFilter: [{ id: "delete" }, { id: "Delete" }, { id: "DELETE"}],
menuMatch: ["default", "download", "properties", "properties_general"]
});

this.folderBrowser.show({
placeholder: "#folderBrowser"
});

this.folderBrowser.on("containerOpened", (args) => {
this.containerOpened = true;
});
});

The otdsToken is an OTDS SSO token that has been previously retrieved and saved.

This code works to get the widget showing the folder in CS that we want. We can download a document, pull up its properties, etc using the FolderBrowserWidget's built in functionality without a problem. However, clicking on the Edit link causes a new browser tab to open to the Content Server UI itself to launch the Office Editor Client. The problem now is that the first time this second tab opens, Content Server isn't authenticated using the client-side cookie that would otherwise have been set if the logged in user had previously signed into Content Server directly.

This is unacceptable as we do not want to force the user to authenticate again. Is there any sort of way that the Edit link in the widget can be customized to provide the OTCS ticket it is already using? Or is this a limitation of Content Server itself that it absolutely has to have a cookie set in order to be logged in to identify the user? Is there any way that we can set this cookie programmatically before the edit link is clicked in the widget?

Find more posts tagged with

Comments

Ferdinand Prantl

This behaviour is currently as-designed. The preferred iomplementation of CS at the customer is using a full SSO. I mean, that for example, after the user logs in to Windows, they don't need to log in web sites, which can be authenticated by reusing the current session.

As long as you implement features using Smart UI components, there is no problem. If you want to open a new page, Smart UI will not control it and the page itself has to take care of authentication. Foe example, xECM offers a button in the FolderBrowserWidget - open a workspace in the full-page window. They pass the authentication ticket from the widget to the new page, so that it doesn't need to authenticate again, if the customer doesn't use SSO.

Now we talk about Smart UI features, which are not implemented by pure Smart UI handlers, but by existing Classic UI functionality, like the Office Editor. Yes, these features share the same problem - the pages are authenticated automatically only, if the browser can authenticate them automatically.

If the button and page come from a module, which you "own", you can implement the authentication yourself, like the xECM team did for their page. The Office Editor is implemented in Smart UI core, and such authentication would have to be done in Smart UI core by OpenText.

Yes, LLCookie is necessary to be present, when you open a new page and don't want to see the extra login. No, three is no workaround to prepare the cookies on the client side. The cookie should be set HTTP-only from security reasons in productive environments.

I had a preliminary discussion abnout a solution in Smart UI core and how to share it with other modules, so that the extra login page can be avoided in environments withotu SSO. It would cover your scenario too. There have been feature requests LPAD-51177 and LPAD-62809 created about this issue.

Szekely_Stephajn

Thanks for this information. Yes, we have a different situation that doesn't allow for SSO, so if this makes it into a future build, that'd be great!