@zoukishi здесь скрипт-кидди в деле?

<img src=xss onload=prompt(9)>

Согласен

@jtlmt

nginx нужен только потому, что ubnt не может придумать масштабируемый и удобный способ управления SSL в UniFi. Let’s Encrypt отлично работает в UNMS, и я надеюсь, что они внедрят это в UniFi. Мы в итоге автоматизировали Let’s Encrypt прямо на Ubuntu-сервере с UniFi и разобрались с проблемами keystore. Для нас это отлично работает и nginx не нужен, но каждому своё.

@systemstateit

Извини, я поспешил с ответом... Контроллер использует этот порт для файла /var/lib/unifi/system.properties. Он всегда будет отправлять письмо с этим номером порта в конце. Варианты:

- Убедить UBNT убрать номер порта из письма и/или дать пользователю возможность как-то это настроить.
- Прекратить проброс порта (или проксирование) и передавать трафик напрямую на 443. С момента моего первого сообщения UniFi больше не требует root для установки или запуска, и поэтому не может привязываться к привилегированному порту. Это ссылка — один из обходных вариантов для решения этой проблемы, который мы используем сейчас.
- Отправлять письмо на транзакционную почтовую платформу, например postfix, который упоминался ранее, или Mandrill от MailChimp. Там настраиваешь правила, корректируешь всё, что надо, и пересылаешь письмо по назначению.

С SSL у UniFi много заморочек. Есть несколько способов заставить Let’s Encrypt работать напрямую на Ubuntu с UniFi, не используя nginx для проксирования. Многие начали использовать nginx перед UniFi именно из-за SSL. Это не обязательно, но многим так привычнее, поэтому так и делают. UniFi всегда будет отправлять письмо с портом, указанным в этом конфигурационном файле, так что пока UBNT не добавит новую переменную, например email.invite.url или что-то подобное, порт из конфига не сменить. Не идеально, нам тоже пришлось много искать решения.

Ах да... теперь всё понятно.

Спасибо за ответ, но я не совсем понимаю, какое из двух предложенных решений ты хочешь применить.  

1) Authbind позволяет не привилегированным приложениям использовать привилегированные порты. У меня с этим проблем нет.  
У меня nginx слушает порт 443, и я использую это, чтобы упростить управление letsencrypt через certbot.  
Unifi запускается на порту 8443, и nginx перенаправляет на него.  
Если nginx слушает на 443, то Unifi не может быть настроен на этот же порт и наоборот.  

2) Второе решение — это просто проброс порта.  
Мне нужно иметь возможность изменить настройку в шаблоне письма, чтобы убрать порт 8443 из URL.  
Сейчас я могу обходить это, вручную добавляя пользователя вместо отправки приглашения по электронной почте — но было бы здорово, если бы можно было сделать это нормально.

Привет, извиняюсь, что поднял эту тему спустя столько времени. Просто интересно, как вам удалось заставить два сервиса слушать один и тот же порт — насколько я знаю, это невозможно? Если только ваш nginx не работал на другом сервере... Спасибо!

Я заметил то же самое и не смог найти способ изменить адреса в письмах. В итоге добавил «unifi.https.port=443» в файл system.properties контроллера. Потом настроил проброс nginx на порт 443. Теперь письма отправляются с правильным портом 443. Интернет --> nginx(443) --> unifi(443)