Confluence with Synchrony, behind IIS reverse proxy

nbic

Background information:

• Windows Server 2012R2
• IIS 8.5
• Confluence 6.7.2-x64
• DNS entry set, pointing to server.mydomain.com

Installed and configured Confluence with pre packed Tomcat, and everything worked fine running on http://myserver:8090/. All good, but I do not want my users to access this through http, nor through port 8090 - since IIS is already serving 80/443, reverse proxy in IIS seems like the obvious solution.

Sadly, this should be a task faced with some hurdles.

• I have edited the tomcat server.xml-file found in the following folder: atlassian/confluence/conf
  <Connector port="8090" connectionTimeout="20000"
                  maxThreads="48" minSpareThreads="10"
                  enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
                  protocol="org.apache.coyote.http11.Http11NioProtocol" proxyName="url.mydomain.com" proxyport="443" scheme="https" secure="true" />
  
  //Is there a way to check from the command line that the running instance is actually loading this configuration? (I have a hunch that it's not.)
  • Confluence is running as a windows-service, is there a way to configure the service itself, i.e with, tomcat8w to set proxyport/scheme and proxyname - to ensure that the correct configuration is loaded?
• I have set up a web.config file for my website in IIS with the following configuration:
  <?xml version="1.0" encoding="UTF-8"?>
  <configuration>
      <system.webServer>
          <rewrite>
              <rules>
                  <clear />
          <rule name="Synchrony HTTP" stopProcessing="true">
              <match url="synchrony/(.*)" />
              <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
              <action type="Rewrite" url="http://localhost:8091/synchrony/{R:1}" />
          </rule>
          <rule name="Synchrony Web Sockets Reverse Proxy" stopProcessing="true">
              <match url="ws://(.*)" />
              <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
              <action type="Rewrite" url="ws://localhost:8091/{R:1}" />
          </rule>
          <rule name="Confluence Reverse Proxy" stopProcessing="true">
              <match url="(.*)" />
              <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
              <action type="Rewrite" url="http://localhost:8090/{R:1}" />
          </rule>    
                                                  
              </rules>
          </rewrite>
          <security>
              <requestFiltering allowDoubleEscaping="true" />
          </security>
      </system.webServer>
  </configuration>
• IIS is set with bindings only on 443 for the website serving my URL

 

I have the following issues within my confluence solution:

• I get an error suggesting my Tomcat configuration is incorrect.
  • The Tomcat server.xml has an incorrect configuration:

    scheme should be 'https'
    proxyName should be 'url.mydomain.com'
    proxyPort should be '443'

• Editing posts does not work as expected, with the following symptoms:
  • The "statusbar" on the bottom says "Connecting...".
  • The following error appears after a while:

    • The editor didn't load this time

      The connection timed out. If it happens again, speak to your Confluence admin. You may be using a proxy server that prevents WebSocket connections.

 

I feel I have double and triple checked everything, but cannot get this to work, so any suggestions would be highly appreciated.

 

 

nbic

This has been resolved. It was shamefully simple.

<Connector port="8090" connectionTimeout="20000"
                maxThreads="48" minSpareThreads="10"
                enableLookups="false" acceptCount="10" debug="0" URIEncoding="UTF-8"
                protocol="org.apache.coyote.http11.Http11NioProtocol" proxyName="url.mydomain.com" proxyport="443" scheme="https" secure="true" />

This was my connector directive in Tomcat. Well, the "proxyport" needs to be "proxyPort", since it's case sensitive. Seems like the whole directive was ignored, due to that typo.