Conflunce behind Webseal and Apache

[Joel Dennis]

We have a Webseal junction configured as www.domain.com/collaboration/, which has a back end apache, with context paths to /jira and /wiki, two tomcat instances on the same host. 

When accessing www.domain.com/collaboration/wiki/ we are initially able to log in, but receive a notification that we are accessing as www.domain.com/wiki/ and then are redirected to login, with the url www.domain.com/wiki/login.action?os_destination=/collaboration/.

The same is true for our jira configuration. Any tips to resolve this? Need to force the url to be www.domain.com/collaboration/wiki/

[AnnWorley]

Please make sure the connector directive in the <application_install_dir>/conf/server.xml file includes the proxyName, proxyPort and scheme, as described in Proxy Support:

The proxyName and proxyPort attributes can be used when Tomcat is run behind a proxy server. These attributes modify the values returned to web applications that call the request.getServerName() and request.getServerPort() methods, which are often used to construct absolute URLs for redirects. Without configuring these attributes, the values returned would reflect the server name and port on which the connection from the proxy server was received, rather than the server name and port to whom the client directed the original request.

[Joel Dennis]

Thanks for your reply Ann.

I set this value to  www.domain.com/collaboration but it does not seem to have any affect. Images and some links (e.g. update base URL popup link) are then redirecting  www.domain.com/collaboration/wiki to  www.domain.com/wiki, with 404 errors.

Any other possibilities?

[Bryan Lim]

Joel,

I am wondering how did you configure your webseal cert on the confluence server?  As we are trying to configure SSO with webseal, and i cant seem to figure out how to add the webseal cert to confluence server.  I was only able to configure my own dns server cert instead.  Thanks!

[Joel Dennis]

Hi Bryan,

We're not configuring SSO for now, so haven't got any insight to assist. Our internal instances are SSO but only use a httpd.

For anyone interested in my original issue, found this article which appears to point to Webseal configuration to resolve the problem. Will test this and report back.

https://publib.boulder.ibm.com/tividd/td/ITAME/SC32-1359-00/en_US/HTML/am51_webseal_guide91.htm