Jira/Confluence via HTTP and HTTPS

[Jörg Godau]

Hello all,

we have the following setup:

https://jira.external.com comes into our network via squid and redirects to http://jira.internal.com:8081  (ie Squid terminates the SSL connection) and convinced JIRA to accept that as a proxied https connection in the server.xml.

Within our network I have set up a DNS redirect from jira.external.com to jira.internal.com so the internal and external users all see the same host.

External users should use HTTPS only and internal users should use HTTP only.

Which URL should I put in JIRA and in Confluence?

If I put https://jira.external.com then the internal users cannot use the links correctly.

If I put http://jira.external.com then the external users end up on an insecure connection.

The same problems apply to confluence.

So - how can I allow Squid to manage my external connections and SSL termination and still be able to have my internal connections go directly to the confluence and jira?

Cheers

Jack...

[Jörg Godau]

Is there not some way to URL rewriting in the squid proxy to get around this problem?

So Confluence and JIRA think they are running under HTTP but squid transforms the requests to HTTPS. Surely this is a fairly normal business case (different internal and external URLs)

[Nic Brough -Adaptavist-]

No, it's not normal to have different internal and external urls - it's a bad design, it's over complicated and has no real benefits. It was a broken design when it was popular 10 years ago, and it's an approach that most businesses have dumped nowadays. You can do it with some complex rewrites though. At a cost of quite a lot of extra processing (it's tiny for any given page, but when you're doing it thousands of times a minute, it starts to add up), and it won't be a complete solution because you still won't be rewriting outgoing emails.

[Daniel Wester]

You won't actually be able to do it through url rewrites depending on the add ons either. Things like JIRA Dashboard gadgets if it's not on the same url as the configured base url. You'd have to start munging the html code which is a pain. Then you have the email urls which complicates things even more (you'll end up getting the wrong url sent to one part or the other). I can't speak for all businesses but I'd (and I have for a large company) run an internal instance and an external instance to avoid any issues (and thus compartmentalize the data) and just link them together OR just have everyone go through the external ssl interface.

[Nic Brough -Adaptavist-]

Good point, although you could get most, and possibly all, of the JIRA rewrites you'd need, Daniel is right about addons - I know of at least two that wouldn't tolerate any form of rewrite. And the stuff you can do would be a Herculean task in itself.

[Daniel Wester]

You'd need to set up another SSL proxy termination point internally and then use DNS magic to give the internal folks that when they request https://jira.external.com . Or you can just have everyone internally use the external point.

JIRA (and Confluence) should only respond to the url in the global settings. If the address in the browser doesn't match it - you're going to see some weird behaviors in on the pages (Team Calendar won't work in Confluence for example).