access to jira via url alias

[Petr Milenin]

good day
we would like to be able to connect to jira via multiple url aliases
is there such a possibility?

[Dirk Ronsmans]

Hi @Petr Milenin ,

As you are on an on premise version you set that up yourself.

Most common way is to use a reverse proxy. There are a couple of proxies you can use but the most common ones are  nginx or apache.

https://confluence.atlassian.com/kb/proxying-atlassian-server-applications-with-apache-http-server-mod_proxy_http-806032611.html

[Petr Milenin]

Hi, thanks for the reply
What about the base url?
It is necessary for the instance to be correctly accessible from several different URLs.

[Dirk Ronsmans]

Hmm thats a tricky one. 

Jira only allows a single base url so I fear it might not be possible to do that. A single redirect/rename that's no problem but having multiple ones seems not possible.

You can always use redirects too of course (dns redirects) so they are available from different url's but the internal base url will be a single one. (afaik)

can you maybe elaborate on why you need this? Maybe we can find another way to do this.

[Nic Brough _Adaptavist_]

No, this will not work.

As Dirk says, you could set up proxies or remappings, but the only site that will work properly is the one the base url is set to.  Trying to use Jira on urls other than the real one will fail your users

It won't break your data, but things like dashboards and reports will fail, users will eventually click on something that takes them back on to the real url, all outgoing links in emails and so-on will only ever refer to the real url, all integrations and external system links will be using the real url or failing, and, and, and.

Dirk asks the question I want to ask - what problem are you trying to solve with multiple urls for a single system?

[nag]

business requirements
different teams working with different projects should work through different urls

thanks for answers
in this case, we will think about dividing projects into instances

[Nic Brough _Adaptavist_]

Ok, a better solution for this problem is "educate the business that having different teams on different urls for a tool intended to work together with is divisive and won't work, and you should question why you think it is a useful thing to do"