HTTPS в режиме разработки

Современные веб-приложения всё чаще требуют защищённого соединения даже на этапе локальной разработки. Многие возможности браузеров работают исключительно через HTTPS или в доверенных локальных окружениях. Parcel предоставляет встроенные механизмы запуска локального сервера разработки с поддержкой HTTPS, что позволяет максимально приблизить условия разработки к реальной производственной среде.

Использование HTTPS в режиме разработки решает несколько важных задач:

  • тестирование функциональности, требующей защищённого соединения;
  • проверка поведения приложения в условиях, близких к production;
  • работа с сервис-воркерами;
  • тестирование API браузера, доступных только через HTTPS;
  • отладка OAuth-авторизации и внешних интеграций;
  • выявление проблем со смешанным контентом (Mixed Content).

Почему HTTPS становится обязательным

Ряд современных Web API намеренно ограничен использованием защищённых соединений. Это связано с вопросами безопасности и защиты пользовательских данных.

К таким технологиям относятся:

  • Service Workers;
  • Web Push Notifications;
  • Web Authentication (WebAuthn);
  • Geolocation API;
  • MediaDevices API;
  • Clipboard API;
  • Payment Request API;
  • HTTP/2 и HTTP/3 особенности взаимодействия;
  • некоторые возможности Progressive Web Apps (PWA).

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

Пример типичной ошибки:

navigator.serviceWorker.register('/sw.js');

При запуске через HTTP браузер может вывести сообщение:

Service workers can only be registered over HTTPS.

Включение HTTPS в Parcel позволяет избежать подобных ограничений.

Базовый запуск HTTPS-сервера

Parcel содержит встроенный dev-сервер. Для запуска через HTTPS используется параметр --https.

Пример:

parcel src/index.html --https

После запуска приложение становится доступным по адресу:

https://localhost:1234

Parcel автоматически создаёт самоподписанный сертификат и запускает сервер с использованием TLS.

Схема работы выглядит следующим образом:

Браузер
    │
 HTTPS
    │
Parcel Dev Server
    │
Исходный код приложения

Использование HTTPS при запуске через npm

Чаще всего запуск Parcel оформляется через сценарии в package.json.

Пример:

{
  "scripts": {
    "start": "parcel src/index.html --https"
  }
}

Запуск:

npm run start

Или:

yarn start

Или:

pnpm start

Такой подход обеспечивает единообразную конфигурацию для всей команды разработки.

Самоподписанные сертификаты

При первом запуске HTTPS Parcel обычно создаёт самоподписанный сертификат.

Особенности таких сертификатов:

  • не подтверждаются центром сертификации;
  • подходят для локальной разработки;
  • вызывают предупреждение браузера;
  • не предназначены для production-среды.

При открытии страницы браузер может показать сообщение:

Your connection is not private

или

NET::ERR_CERT_AUTHORITY_INVALID

После подтверждения исключения страница продолжит работу в защищённом режиме.

Использование собственных сертификатов

Во многих проектах требуется использовать заранее подготовленные сертификаты.

Причины:

  • тестирование корпоративной инфраструктуры;
  • работа с внутренними доменами;
  • имитация production-среды;
  • интеграция с внешними системами авторизации.

Parcel позволяет указать собственные сертификаты через параметры командной строки.

Пример:

parcel src/index.html \
  --https \
  --cert certs/server.crt \
  --key certs/server.key

Структура проекта:

project/
│
├── certs/
│   ├── server.crt
│   └── server.key
│
├── src/
│   └── index.html
│
└── package.json

В этом случае Parcel использует указанные сертификаты вместо автоматически созданных.

Генерация локального сертификата через OpenSSL

Часто для разработки создаются собственные сертификаты.

Создание приватного ключа:

openssl genrsa -out server.key 2048

Создание сертификата:

openssl req -new -x509 \
  -key server.key \
  -out server.crt \
  -days 365

После выполнения команд появятся файлы:

server.key
server.crt

Далее их можно подключить к Parcel:

parcel src/index.html \
  --https \
  --cert server.crt \
  --key server.key

Работа с локальными доменами

Иногда приложение должно работать не через localhost, а через собственное доменное имя.

Пример:

my-app.local

Для этого в системный файл hosts добавляется запись:

127.0.0.1 my-app.local

После настройки можно запускать Parcel:

parcel src/index.html \
  --host my-app.local \
  --https

Доступ к приложению:

https://my-app.local:1234

Такой подход полезен при тестировании:

  • OAuth-провайдеров;
  • Cookie-политик;
  • CORS-настроек;
  • междоменных запросов.

HTTPS и Service Workers

Service Worker является одной из наиболее распространённых причин включения HTTPS во время разработки.

Регистрация:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js');
}

Без HTTPS регистрация может завершиться ошибкой.

После запуска Parcel с HTTPS сервис-воркер получает возможность:

  • кэшировать ресурсы;
  • обрабатывать сетевые запросы;
  • обеспечивать офлайн-режим;
  • управлять push-уведомлениями.

Пример простого сервис-воркера:

self.addEventListener('install', event => {
  console.log('Service Worker installed');
});

HTTPS и Progressive Web Apps

Parcel часто используется при разработке PWA-приложений.

Типичная структура:

src/
├── index.html
├── manifest.json
├── sw.js
└── app.js

Manifest:

{
  "name": "My App",
  "short_name": "App",
  "start_url": "/",
  "display": "standalone"
}

Для полноценного тестирования PWA необходим HTTPS.

Без защищённого соединения браузер может:

  • игнорировать сервис-воркер;
  • отключать установку приложения;
  • блокировать некоторые PWA-функции.

HTTPS и WebAuthn

Технология Web Authentication используется для входа с помощью:

  • отпечатков пальцев;
  • аппаратных ключей безопасности;
  • встроенных механизмов биометрии.

Создание учётных данных:

navigator.credentials.create({
  publicKey: options
});

WebAuthn требует безопасного контекста.

При использовании Parcel HTTPS можно полноценно тестировать:

  • регистрацию пользователей;
  • аутентификацию;
  • работу аппаратных токенов;
  • Passkeys.

HTTPS и Geolocation API

Получение координат пользователя:

navigator.geolocation.getCurrentPosition(
  position => {
    console.log(position.coords);
  }
);

Большинство современных браузеров требуют защищённого соединения для доступа к геолокации.

HTTPS в Parcel позволяет проверять:

  • запрос разрешений;
  • обработку отказов;
  • сценарии получения координат;
  • работу картографических сервисов.

Безопасные Cookie используют атрибут Secure.

Пример:

Set-Cookie: session=abc123; Secure

Такие Cookie:

  • передаются только по HTTPS;
  • не работают через обычный HTTP;
  • активно используются в production-приложениях.

Запуск Parcel через HTTPS позволяет тестировать реальные сценарии работы сессионных данных.

HTTPS и Mixed Content

Mixed Content возникает, когда HTTPS-страница загружает ресурсы через HTTP.

Пример:

<script src="http://example.com/script.js"></script>

Браузер может заблокировать такой запрос.

Типичное сообщение:

Mixed Content: The page was loaded over HTTPS,
but requested an insecure resource.

Во время разработки через HTTPS подобные проблемы обнаруживаются заранее, ещё до публикации приложения.

Корректный вариант:

<script src="https://example.com/script.js"></script>

Настройка порта при использовании HTTPS

По умолчанию Parcel использует порт:

1234

При необходимости его можно изменить.

Пример:

parcel src/index.html \
  --https \
  --port 3000

Адрес приложения:

https://localhost:3000

Это особенно полезно при работе с несколькими проектами одновременно.

Совмещение HTTPS и Hot Module Replacement

Одним из преимуществ Parcel остаётся поддержка HMR.

При изменении файла:

console.log('Version 2');

Parcel автоматически:

  1. пересобирает модуль;
  2. отправляет обновление через WebSocket;
  3. обновляет страницу без полной перезагрузки.

HTTPS не мешает работе HMR.

Схема взаимодействия:

Редактор кода
      │
      ▼
 Parcel
      │
 WebSocket (WSS)
      │
      ▼
 Браузер

При HTTPS соединение WebSocket также переводится в защищённый режим (wss://).

Использование HTTPS в монорепозиториях

В крупных проектах часто применяется структура:

monorepo/
│
├── apps/
│   ├── admin/
│   └── client/
│
├── packages/
│   ├── ui/
│   └── utils/
│
└── package.json

Каждое приложение может запускаться отдельно:

parcel apps/admin/index.html --https

или

parcel apps/client/index.html --https

Использование HTTPS обеспечивает одинаковые условия разработки для всех частей системы.

Типичные проблемы и способы решения

Ошибка сертификата

Сообщение:

NET::ERR_CERT_AUTHORITY_INVALID

Причины:

  • самоподписанный сертификат;
  • отсутствие доверия к сертификату;
  • неправильная цепочка сертификатов.

Решения:

  • добавить сертификат в доверенные;
  • использовать локальный центр сертификации;
  • создать новый сертификат.

Конфликт порта

Сообщение:

Port 1234 is already in use

Решение:

parcel src/index.html \
  --https \
  --port 4000

Ошибка чтения сертификата

Сообщение:

ENOENT: no such file or directory

Причины:

  • неверный путь;
  • отсутствующий файл;
  • опечатка в имени сертификата.

Проверка:

ls certs

Несоответствие доменного имени

Сообщение браузера:

Certificate does not match hostname

Причина заключается в том, что сертификат выпущен для одного домена, а приложение открывается через другой.

Пример:

Сертификат: my-app.local
Открытие: localhost

Имена должны совпадать.

Практические рекомендации

HTTPS рекомендуется включать всегда, если проект использует:

  • Service Workers;
  • PWA;
  • OAuth;
  • OpenID Connect;
  • Secure Cookie;
  • Geolocation API;
  • WebAuthn;
  • Push Notifications;
  • внешние платёжные системы;
  • современные браузерные API.

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

Локальные домены позволяют точнее воспроизводить production-сценарии, особенно при тестировании аутентификации и междоменных взаимодействий.

Раннее обнаружение Mixed Content значительно снижает количество проблем при развёртывании приложения на боевом сервере.

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

Оглавление