How to bypass a reverse proxy or SSL in Application Links

Still need help?

The Atlassian Community is here for you.

Ask the community

When working with Application Links, it may be necessary to bypass any existing reverse proxy or SSL configuration, without disrupting normal usage for your instances. 

You may also wish to use this process to bypass a proxy during the troubleshooting process.

If you are looking for steps on how to bypass SSL and Proxy to test network connectivity, please refer to How to bypass a Proxy and SSL to test network connectivity.

  • You may wish to bypass any overhead associated with the reverse proxy, or SSL configuration
  • Bypassing the reverse proxy reduces the amount of traffic incoming to the reverse proxy.

Application links that bypass the reverse proxy can be configured with the proxied URL. This means that users of the applications will still see the proxied URL, but the applications will communicate over the unproxied URL.

To bypass a reverse proxy or SSL configuration, introduce an additional HTTP connector in Tomcat. The following is a bare minimum HTTP connector for use in Tomcat across Atlassian Products:
<Connector port="8080" connectionTimeout="20000" maxThreads="200" minSpareThreads="10" 
	enableLookups="false" acceptCount="10" URIEncoding="UTF-8" />

To make use of this, edit the server.xml file for the application in question. The connector must be added inside the Service element. You will also need to restart the application to take effect.

You should adjust the value of the port attribute in the new connector. Ensure to use a port that isn't already used by any application on the same physical machine. For example, if you have JIRA listening for incoming connections on port 8080 (which is in turn connected to a reverse proxy), you should change your new connector to something else, such as 8081.

if web.xml has been edited as per our documentation on connecting over ssl services, the following lines will need to be removed temporarily to bypass URL redirection.

Click here to expand...
<security-constraint>
  <web-resource-collection>
    <web-resource-name>all-except-attachments</web-resource-name>
    <url-pattern>*.jsp</url-pattern>
    <url-pattern>*.jspa</url-pattern>
    <url-pattern>/browse/*</url-pattern>
	<url-pattern>/issues/*</url-pattern> 
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

As of Bitbucket Server 5.0, you can't configure any Tomcat connectors directly as the application runs on Spring Boot.

The usual server.xml configurations have been replaced by properties that need to be configured on <Bitbucket home directory>/shared/bitbucket.properties

Similarly, you can't configure web.xml.

In order to add a new HTTP connector for this purpose, this is the only configuration you need:

server.additional-connector.1.port=8080

Please read through Migrate server.xml customizations to bitbucket.properties

 

 

The location of your server.xml file depends on your application, operating system, and installation location. 

Common default installation locations for Atlassian applications are:

  • Linux: /opt/atlassian/<application-name>
  • Windows: C:\Program Files\Atlassian\<application-name>
  • Windows: C:\Atlassian\<application-name>

Locations in Atlassian application's folder structure:

Application server.xml location
Bamboo <install-path>/conf/
Confluence <install-path>/conf/
Crowd <install-path>/apache-tomcat/conf/
Crucible As for Fisheye.
Fisheye The Fisheye configuration file is config.xml, see Configuring the Fisheye web server and How to enable Fisheye/Crucible to listen to web requests on additional ports.
JIRA applications <install-path>/conf/
Bitbucket Server 5.0

N/A, replaced by <Bitbucket home directory>/shared/bitbucket.properties

Please read through Migrate server.xml customizations to bitbucket.properties

Bitbucket Server 4.0 – 4.14 <Bitbucket home directory> /shared/server.xml
Stash 3.8 – 3.11

<Stash home directory>/shared/

If you are on any of these later releases but your server.xml does not exist in the directory above, it means that you are running from the <install-path>/conf/server.xml.

We recommend that you copy <install-path>/conf/server.xml into <Stash home directory>/shared/ that way you won't need to worry about this when you upgrade your instance.


Stash 3.7 and earlier <install-path>/conf/

<install-path> refers to where the application was installed on your system.

 

 

Last modified on Aug 18, 2017

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.