Оглавление
1. Введение 2.Бэкэнд 2.1. Инфраструктура .2.2. Доменное имя.
SSL (мы находимся здесь) 2.3. Серверное приложение на Dart. .
3.Веб 3.1. Пробка «В разработке» .
4.Мобильный .
отказ от ответственности (на основе комментариев к предыдущей статье) Данная статья не является полностью самостоятельной и является продолжением серии «Сервис» на языке Dart. Начало здесь .
Предметом этой статьи является только то, что включено в заголовок: имя домена и шифрование соединения.
Облаков, оркестрации, масштабирования, K8, AWS, GKE здесь нет. Автор знает, что такой подход не современен и не моден.
Более того, автор признает, что общается в окружении «ретроградов», многие из которых вообще считают недопустимым передачу критически важных данных и сервисов за пределы подконтрольного периметра.
Автор не может отказаться от использования Dart на сервере в пользу других языков и технологий, поскольку сама концепция данной серии статей заключается в реализации работающего сервиса.
на языке дартс для всех уровней приложений: серверных, веб- и мобильных клиентов.
Перечень вопросов, подлежащих рассмотрению при реализации заявок, был выбран автором по собственному усмотрению.
Список может быть расширен читателем соответствующими комментариями к этой или последующим статьям.
Предлагайте, мы попробуем это сделать.
Список вопросов Декомпозиция приложения на компоненты и слои.
Внедрение зависимостей (генерация шаблонного кода) Создание собственного серверного приложения ОРМ.
Генерация схемы и миграции для базы данных.
oAuth2 + авторизация JWT. Изолированный сервер авторизации.
Диплинки (универсальные ссылки/ссылки на приложения).
Бесшовная интеграция с веб-приложением
Маршрутизация приложений
Общение в реальном времени (веб-сокеты)
Адаптивный флаттер макета
Доменное имя
В последний раз В итоге мы запустили веб-сервер NGINX в Docker-контейнере, распространяя статический файл index.html. На этот раз мы расширим функционал веб-сервера, добавив шифрование данных и принудительное перенаправление с http на https.
Для этого вам нужно будет решить организационную проблему: дело в том, что сертификат шифрования можно получить только на доменное имя или группу имен.
По этой причине мы идем к любому из регистраторов доменных имен и выбираем имя, соответствующее бренду (цель, слоган и т. д.), не забывая о цели.
доменные имена верхний уровень.
В моем случае dartservice.ru подойдет идеально.
В процессе регистрации вы должны заполнить форму с информацией о владельце, включая полное имя, почтовый адрес и адрес электронной почты.
Затем вам необходимо зайти в панель управления регистратора для управления записями DNS и сделать три записи: Минимум две записи NS. Это имена серверов доменных имен регистратора, и их имена сообщается регистратором при покупке доменного имени.
Запись.
Это непосредственно запись связи между доменным именем и IP-адресом сервера.
В моем случае записи DNS выглядят так:
Сделав это, не стоит ожидать немедленных результатов.
Обмен информацией между DNS-серверами обычно занимает от 1 до 12 часов для зоны RU. После чего.
добавим в проект еще один тест /test/http/client.http 
SSL
В целом, конечно, SSL-протокол - устаревшее название.Новые версии протокола называются TLS 1.0.1.3, но механизм остается прежним — шифрование данных при переходе между протоколом прикладного уровня (в нашем случае HTTP) и протоколом транспортного уровня (TCP/IP).
На самом деле необходимо: Получите сертификат шифрования в специальном центре сертификации, подтверждающий право собственности на соответствующий домен.
Загрузите сертификат на сервер NGINX. Настройте веб-сервер для шифрования соединения.
Принудительно переключить соединения, установленные через http на https. На данный момент общепринято использовать бесплатные сертификаты, автоматически выдаваемые сервисом.
Одним из ограничений таких сертификатов является срок действия.
Всего 90 дней.
После чего сертификат необходимо получить повторно.
Разработан протокол автоматического (без вмешательства человека) получения сертификатов АКМЕ и приложения, которые периодически выполняют действия по проверке владения доменом.
Давайте зашифруем рекомендации с помощью приложения сертификатбот .
Он написан на Python и требует установки собственного репозитория и Python3. Поэтому мы будем использовать докер-контейнер с установленным certbot из реестра DockerHub .
Давайте выберем последнюю стабильную версию сертификатбот/сертбот:v1.5.0 .
Теперь рассмотрим механизм получения сертификата по протоколу ACME: При первом запуске Certbot генерирует закрытый и открытый ключи, затем создает учетную запись администратора домена в службе Let’s encrypt, передавая открытый ключ и информацию о домене.
После этого Let’s Encrypt передает сообщение, которое сертификатбот должен подписать закрытым ключом и вернуть обратно.
Certbot должен разместить на сервере специальный файл, доступный для чтения в dartservice.ru/.
well-known/acme-challenge чтобы подтвердить право собственности на этот домен.
Certbot компилирует запрос сертификата , отправляет его в Let’s Encrypt и получает взамен сертификат для домена.
Давайте добавим контейнер приложения в наш скрипт docker-compose.yaml: 
Новая опция здесь команда : вот команда, которая будет выполнена после запуска контейнера.
В этом случае обязательно (получите сертификат).
Получение сертификата происходит в интерактивном режиме, то есть вам необходимо последовательно ответить на несколько вопросов.
Передача флагов после команды позволяет сделать это без вмешательства человека: --webroot (метод проверки) --webroot-path=/usr/share/nginx/html/letsencrypt (путь, по которому будут находиться файлы подтверждения владения доменом) -- email admin @email.com (электронная почта администратора домена) --agree-tos (принять условия лицензионного соглашения) --no-eff-email (не передавать электронную почту разработчикам certbot) -d dartservice.ru (список доменов ).
Настроим контейнер NGINX: 
Изменения здесь заключаются в открытии порта https (443) и монтировании папок с SSL-сертификатом и файлами подтверждения владения доменом.
Важным параметром является папка с ключом Диффи-Хеллмана.
Вкратце: этот ключ нужен для безопасного обмена ключами шифрования между сервером и клиентом при установлении соединения.
Подробно Здесь .
Сгенерируем такой ключ, но столкнемся со следующей проблемой: создание ключа осуществляется программой OpenSSL , это консольная утилита Linux, которая вряд ли появится на нашем компьютере с Windows. Самое простое решение — запустить наш скрипт, зайти в консоль контейнера сеть и создайте там ключ, передав в выходном пути файла папку хоста, смонтированную в контейнере: Запустим скрипт:
Запрашиваем список запущенных контейнеров:docker-compose up -d
docker-compose ps
Откройте консоль контейнера:
docker exec -it srv_web_1 bashНачинаем генерировать ключ в папке конфигурации NGINX (которая, как мы помним, монтируется с хоста):
openssl dhparam -out /etc/nginx/conf.d/dhparams.pem 2048
Переместите ключ в .
/dhparams/dhparam-2048.pem.
Выйдите из консоли контейнера, нажав Ctrl-D, и остановите скрипт: docker-compose down
Теперь изменим конфигурацию NGINX .
/conf.d/defaulf.conf: 
Давайте добавим новое местоположение ^~ /.
well-known/acme-challenge для распространения статических файлов из папки /usr/share/nginx/html/letsencrypt. Здесь будут расположены файлы подтверждения сертификата бота.
Настроим перенаправление для всех остальных запросов на https. Все готово для первого получения SSL-сертификата.
Скопируем наш проект на VPS в новую папку /opt/srv_1/ командой: scp -r .
/* [email protected]:/opt/srv_1/
Подключимся из VScode через SSH к VPS.
Зайдем в папку работающего сервера: cd /opt/srv_0/
и остановите скрипт: docker-compose down
Теперь перейдите в папку нового сервера cd /opt/srv_1/ и запустите скрипт: docker-compose up
В консоли мы видим, что certbot создал файл подтверждения zeS4O87S6AfRQ3Kj4MaBlBFZx3AIiWdPn61DwogDMK4 и сообщил об этом сервису Let’s encrypt, который, в свою очередь, запросил этот файл с четырех разных IP-адресов, а затем выдал сертификат. Сертификат в виде полной цепочки и закрытого ключа сохранялись в соответствующей папке.
Сертификат действителен 90 дней (до 05.10.2020).
Пришло время создать второе место для безопасного соединения в конфигурации NGINX на сервере .
/conf.d/defaulf.conf: 
Давайте перезапустим скрипт docker-compose restart
Посмотрим, как браузер отреагирует на наш сертификат: 
Google Chrome доволен нашим сертификатом.
Теперь задача посложнее — проверим безопасность и доступность нашего SSL-соединения для разных браузеров.
https://www.ssllabs.com/ssltest/ .
Введите адрес и получите результат: 
С сертификатом и обменом ключами всё хорошо (спасибо Диффи-Хеллману), но тестовому роботу снизили рейтинг («B» — это «4» по нашему мнению) за поддержку устаревших протоколов TLS1.0 и TLS1.1. Отключить их в конфигурации NGINX несложно, однако, просматривая отчет о тестировании дальше, мы видим, что, например, браузеры некоторых мобильных устройств в этом случае не смогут подключаться: 
Осталось выполнить несколько сервисных задач.
Количество попыток получения сертификата на домен не должно превышать 5 в течение 7 дней.
После этого сервис Let’s encrypt может нас заблокировать.
Однако при запуске сценария, когда разработка приложения каждый раз сертификатбот предпримет такую попытку, поэтому в скрипте docker-compose.dev.yaml меняем параметр команда контейнер сертификатбот : 
Флаг --dry-run — это тестовый запуск без получения сертификата.
Давайте напишем тест: 
Источник github .
Заключение
Итак, на этом этапе мы защитили связь сервера с клиентскими приложениями и научили браузеры «доверять» нашему домену.В следующей статье мы будем серфинг Давай напишем развевающаяся паутина страницу с обратным отсчетом до запуска нашего сервиса, мы соберем ее и разместим на нашем сервере.
Теги: #Nginx #Разработка мобильных приложений #docker #flutter #dart #fullstack development #surf
-
Хороших Выходных
19 Oct, 24 -
Флешка Для Шпиона
19 Oct, 24 -
Наш Великий Русский Компьютерный Язык...
19 Oct, 24 -
Opentask — Простой Сервис Задач
19 Oct, 24 -
Страсть К Физике
19 Oct, 24 -
Откуда Берется Дешевый Трафик?
19 Oct, 24
