nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Errors after adding proxyName, proxyPort and scheme on Firefox and IE

Rodrigo Fernandes

Hi guys!

We are having some problems with JIRA (using version 7.3.8) after we added proxyName, proxyPort and scheme properties on server.xml.

When trying to create a new issue with Firefox and IE the modal create screen is not shown, but with Google Chrome it works normal. And before we did the change on server.xml everything worked fine in any browser.

Does anybody had the same issue? How did you guys solved it?

Thanks!

Best regards,

Rodrigo Kondo

Accepted answers

Andy Heinzer

If your server.xml only has a single connector defined, and you just set that to use the proxyName, proxyPort, and scheme parameters, then all the traffic going to that connector should be going through the reverse proxy first. That is what Jira's Tomcat instance is expecting to happen with those parameters set.

If that is not happening then that would explain why some internal users are seeing this problem.

Jira will allow you though to setup multiple connectors in that Tomcat server.xml file. So one solution here might just be to create a new connector that operates on a different port number, and does not use those proxyName, proxyPort directives. This way the internal users could still connect to the site without having to go through this reverse proxy.

The alternative here is to send all traffic through the reverse proxy, internal and external and bypass this problem that way.

Regards,
Andy

Rodrigo Fernandes

Found the workaround for my problem in here: https://community.atlassian.com/t5/Answers-Developer-Questions/Jira-7-rest-api-XSRF-check-failed-for-post-issue-with/qaq-p/488706

It turns out to be that the REST API has problems with the default User-Agent String of Firefox, e.g. (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0)

Overwriting the User-Agent String with some dummy value worked.

All comments

Suhas P

Are you using apache for reverse proxying?

Rodrigo Fernandes

Reverse proxy with authentication, but only for external access. For internal access in the company the authentication is not required.

Andy Heinzer

If that is not happening then that would explain why some internal users are seeing this problem.

The alternative here is to send all traffic through the reverse proxy, internal and external and bypass this problem that way.

Regards,
Andy

Rodrigo Fernandes

Hi Andy,

this solutions looks promising!

My actual connector in using port 8080 with the proxy parameters. I duplicated the connector and changed this new one to port 8082, and them when utilizing JIRA through 8082 port, JIRA works normal again on Firefox and IE, but through 8080 the errors continues.
So I changed the ports, the connector with proxy parameters now is on 8082 and the other one is on the 8080. And then some gadgets in the dashboards are not shown on Firefox and IE.

What configuration do you recommend? Where to use the proxy parameters? (the reverse proxy is set on the 8080 port, but we can change it)

Thanks!

Best regards,
Rodrigo Kondo

Andy Heinzer

Hi Rodrigo,

The problem you will encounter here is that within Jira you have to set a Base URL to a single specific address. This is telling the Jira application what URL is being used to access the site. While you can technically still reach the site from other addresses, like the IP, or a different interface address, or a fully qualified domain name (fqdn), items like the dashboard gadgets are only going to work when visiting the site from at the set Base URL. This is because the Jira Application itself will make network requests to the defined Base URL of the application. If Jira can't reach its base URL because of your network setup, then items like dashboard gadgets are not going to work correctly.

This is why it would probably be best for users to all access Jira on the same URL (both internal and external users). If that means sending all traffic through the reverse proxy, well, it might be best to do so just to provide a consistent experience for all users. As long as your reverse proxy is reliably available, then you shouldn't really see any noticeable performance drop in regards to page loading or responsiveness in the site.

You can still keep an additional unproxied connector for internal use, just keep in mind that this exists here for admin use or as a backup for internal users. I like to keep this unproxied connector as a means to troubleshoot potential problems that reverse proxies can cause for Jira in regards to displaying pages properly.

In most cases, if Jira is setup to use port 8080 on tomcat and that connector is using the proxyName and proxyPort directives, then on the proxy side of things, frequently you can configure the proxy to accept webtraffic on a different port/address and then redirect that traffic to the Jira server on port 8080. This is how most systems running a public Jira are configured. That way you can use a url like http://jira.example.com that the proxy accepts traffic to over port 80. From there the proxy has a re-write rule to then direct that traffic to the jira address on port 8080.

We have an overview of how you can configure both Jira and a common proxy like Apache in Proxying Atlassian server applications with Apache HTTP Server (mod_proxy_http).

I hope this helps.
Andy

Regards,
Andy

Rodrigo Fernandes

Looks like we are already setting things correct in here.

The real problem seems to be more like this one: https://confluence.atlassian.com/jirakb/rest-api-calls-with-a-browser-user-agent-header-may-fail-csrf-checks-802591455.html
But I couldn't get how to solve the problem. Can I change the way REST API works removing the header? If yes, how do I do that?
Or how can I add an Origin or Referrer header to the REST API call?

Best regards,

Rodrigo Kondo

Rodrigo Fernandes

Found the workaround for my problem in here: https://community.atlassian.com/t5/Answers-Developer-Questions/Jira-7-rest-api-XSRF-check-failed-for-post-issue-with/qaq-p/488706

It turns out to be that the REST API has problems with the default User-Agent String of Firefox, e.g. (Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0)

Overwriting the User-Agent String with some dummy value worked.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira