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?
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.
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)
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.
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?
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.
Hello, Community! My name is Gosia and I'm a Product Manager on Jira Server and Data Center here at Atlassian. Since 2002 when we launched our public issue tracker, jira.atlass...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs