Redirect links in Camunda Cockpit don't work under different contexts

Hello,
we have a Camunda service running under a web context which is like
https://projectx.companyname.de:9443/environment42/processcontrol-engine/camunda-welcome/index.html
but the internal links and ressources of the Cockpit point to hard-coded web contexts like /camunda/app/welcome/default/# which results in links like
https://projectx.companyname.de:9443/camunda/app/welcome/default/#
which means that the context /environment42/processcontrol-engine/ is gone.
Also Nginx doesn’t help us, because the web-packed Javascript libraries load resources from outside our context.
Does anyone has an idea to solve this problem?

1 Like

What I found out so far (for my Spring Boot Embedded Camunda app):

  1. The Camunda web application uses an APP_ROOT placeholder in index.html which is replaced by the servlet context root. Unfortunately that has the effect that the browser expects to find its resources relative to /, hence the effect you describe. It is not possible to define a relative context root for a servlet. I changed the camunda context root so that it is correct from the perspective of the browser (like /foo/camunda) and added a Zuul server in front of the camunda app. Requests from the browser to https://my.public.com/foo are routed to Zuul, which has a static mapping /camunda/** pointing to the camunda index resource at http://camunda.internal:port. That way, if the browser requests resources below https://my.public.com/foo/camunda, they arrive at my camunda app. Not beautiful, but it gives me an index.html with the correct host-relative resource urls from the browser perspective which are served correctly. Something similar might be possible with nginx. But there is more…
  2. When the camunda webapp receives requests to /, it redirects with http 302 responses to absolute urls which are wrong from the browser perspective, i.e. if you request https://my.public.com/foo/camunda, and you route that request to http://camunda.internal:8888, it will respond with http redirects to the absolute url http://camunda.internal:8888/app/welcome/default/. A workaround for this is to make sure the initial browser request for the camunda app avoids those redirects, e.g. by letting the browser ask for https://my.public.com/foo/camunda/app/welcome/default/ or by providing the same kind of redirecting outside of Camunda before a request ever hits the tasklist. I haven’t found the code which is responsible for these redirects yet, I would be grateful if someone pointed me in the right direction here…

It seems not uncommon to serve web applications by mapping a path segment of an incoming url to some internal host, but Camunda apparently is not expecting that. If I am not mistaken, it really would like to run at a host-relative url starting with / and is not prepared for setups which require url path segments before Camunda’s own path.