2016-08-11 5 views
0

Я недавно установил экземпляры Crucible в AWS, подключенные через ELT HTTPS. У меня есть обратный прокси-сервер nginx в экземпляре, а также перенаправление HTTP-запросов на HTTPS.Атласский тигель через AWS ELB с HTTPS

Это частично работает. Однако сам Crucible не знает, что он работает по HTTPS, поэтому он поддерживает смешанный контент, а запросы ajax часто прерываются из-за конфликтов HTTP -> HTTPS.

Я нашел документацию для установки сертификата в Crucible непосредственно ...

https://confluence.atlassian.com/fisheye/fisheye-ssl-configuration-298976938.html

Однако я действительно предпочел не делать это таким образом. Я хочу, чтобы HTTPS был завершен на ELB, чтобы упростить управление централизованно через AWS.

Я также нашел документацию для использования тигля через обратный прокси-сервер ...

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

Однако это конкретно не иметь дела с HTTPS.

Все, что мне действительно нужно, - это способ гарантировать, что Crucible не поддерживает контент с жестко закодированными внутренними HTTP-ссылками. Он должен либо отказаться от протокола, либо установить HTTPS для ссылок.

ответ

1

Настройка конфигурации обратного прокси-сервера должна помочь в этом. Под Administration >> Global Settings >> Server >> Web Server установлено следующее:

Proxy scheme: https Proxy host: elb.hostname.com Proxy port: 443

и перезапустить тигель.

1

Конфигурация в пользовательском интерфейсе - один из способов. Вы также можете изменить config.xml в $ FISHEYE_HOME:

<web-server site-url="https://your-public-crucible-url"> 
    <http bind=":8060" proxy-host=“your-public-crucible-url" proxy-port="443" proxy-scheme="https"/> 
</web-server> 

Убедитесь, что выключение FishEye/Crucible перед внесением этих изменений.

AFAIK, эта конфигурация - единственный способ рассказать внутреннюю Jetty FishEye/Crucible, чтобы быть в курсе обратного прокси перед ними.