Назад | Перейти на главную страницу

Как перейти с локального сервера разработки Django на закрытый общедоступный тестовый сервер?

Я работаю над веб-сайтом, который не должен быть открыт для публичного просмотра. В настоящее время я разрабатываю на своем локальном компьютере, используя manage.py и runserver.

Однако я хочу сделать сайт общедоступным только для некоторых людей. Эти люди не разработчики, поэтому им не нужен доступ к коду. Кроме того, поскольку они не являются разработчиками, это должно быть несколько удобное решение. Им просто нужен доступ, чтобы просматривать мои текущие изменения 24 часа в сутки.

Я подумывал о том, чтобы что-то сделать с ALLOWED_HOSTS, но эти люди уже в пути и входят в систему с разных IP-адресов, некоторые из которых, я уверен, являются динамическими.

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

Итак, как лучше всего поделиться сайтом Django с ограниченной аудиторией, не являющейся разработчиками, во время разработки, гарантируя, что случайная публика не имеет доступа? Есть ли пакет или услуга для этого?

Спасибо.

Одна из возможных идей - дать тестировщикам клиентские сертификаты X509.

  • Человек вводит свой сертификат и закрытый ключ в свой браузер. В моем Firefox это в Настройках -> Конфиденциальность -> прокрутите до самого низа -> Просмотр сертификатов -> вкладка Ваши сертификаты -> Импорт
  • Ваш конец SSL / TLS-соединения (обратный прокси-сервер nginx, haproxy, apache и т. Д.), Хотя и прослушивает общедоступный порт 443, настроен не только для обслуживания обычного сертификата на стороне сервера, но и для требования успешной проверки сторона клиента сертификат (очевидно, вы настраиваете принимать только сертификаты тестера).
  • Это расширенные параметры SSL / TLS на вашей стороне, поэтому, например, реализация https в AWS ALB недостаточна.
  • Таким образом можно разрешить только использование https, а не HTTP в виде обычного текста.
  • Это никак не влияет на содержимое http GET / POST / cookie, поэтому не влияет на схемы аутентификации на этих уровнях.
  • Неавторизованные браузеры отображают ошибку SSL / TLS - они вообще не могут передавать GET / POST.