With the launch of the new My Support Portal, we replaced the identity management system behind the OpenText Connect authentication tool with OpenText™ Identity and Access Management (IAM) as your single-entry point to OpenText developer and OpenText support resources.

For our Developer Trial users, if you experience any issues signing in to the Developer site or our Developer console, please refer to these articles.

Reverse Proxy for ACS to use with xCP Advanced Viewer

basinilya
basinilya
in Documentum #1

Hi. In Our xCP application we have our JMS and web application nodes behind a firewall and only the load balancer is accessible from the internet.

Currently, the load balancer only connects to the web application nodes. Now we want to add the xCP Advanced Viewer widget to our app.

When previewing PDFs the xCP Advanced Viewer widget first requests some info at [/contents/{typeName}/{objectId}/view] mapped to the 'viewerViewController' in xCP.

The controller internally calls IDfSysObject.getAcsRequests() and returns the full ACS URLs as part of the JSON document.

Then the viewer widget requests the PDF payload at the received ACS URL and renders it.

We see that the ACS URLs always start with the host name of one of the JMS nodes and naturally are not accessible from the internet.

So how to properly circumvent this? Should we alter the ACS URL in the viewerViewController response when it goes via the load balancer?

Comments

  • DCTM_Guru
    DCTM_Guru
    #2

    I'm not this is Documentum issue as much as firewall/security configuration that your network folks need to figure out. Changing the URL will probably not solve your load balancing issue.

  • Hicham Bahi
    Hicham Bahi E
    edited May 31, 2021 #3

    I'm not familiar with xCP Advanced Viewer widget but you should be able to disable ACS if you don't want to expose it outside firewall. The widget should then use another technique to retrieve the content (e.g. via a servlet which uses DFC getfile). Checkout the widget documentation.

  • basinilya
    basinilya
    edited June 5, 2021 #4
    I noticed that if in a clustered environment I replace the host part in an ACS document URL with a neighbor node the link is still valid. This makes me wonder what purpose the "&servername=" URL parameter serves because it doesn't have to match the host part and if I try to change this parameter it will invalidate the "&signature=" parameter.

    What if I set dm_acs_config.acs_base_url[0] to my load balancer URL? Can I then configure the load balancer to randomly connect to one of the JMS instances by altering the host part in the requested URL? Will it have performance impact if I keep the original "&servername=" in the URL?
  • DCTM_Guru
    DCTM_Guru
    #5

    "What if I set dm_acs_config.acs_base_url[0] to my load balancer URL? Can I then configure the load balancer to randomly connect to one of the JMS instances by altering the host part in the requested URL?"

    • You can try. The LB is designed to route traffic to various servers based on url. I'm not sure what will happen if you send request to ACS that doesnt happen to have content cached. I believe by design if the file is NOT in ACS, the app (ie xCP Adv Viewer) should retrieve the content via xCP app server.

    "Will it have performance impact if I keep the original "&servername=" in the URL?"

    • Performance impact is relative term. Unless you are operating in WAN (ie server in US and user in Asia connecting to the US server) or the file is very large (>100+ MB), the performance gain of ACS is minimal. Internet speeds has improved exponentially since ACS was built. Try it and see it.

Categories