HTTP-аутентификация в PHP | Руководство по PHP | PHP.RU

Аутентификация на основе токенов без побочных каналов

Подробнее: Сплит-токены: протоколы аутентификации на основе токенов без побочных каналов

Если говорить о базах данных (предыдущий раздел): вы знали, что запросы SELECT теоретически могут быть источником утечек информации о тайминге?

Простые меры защиты:

1. Режьте свои токены аутентификации пополам.
2. Одну половину используйте в запросах SELECT.
3. Вторую половину проверяйте за фиксированное время (constant-time).

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

Что делать дальше?

И вот мы подбираемся к самому интересному: а где хранить пароли и в каком виде? Давайте сначала подумаем, где их хранить.

Что такое сессии?

Попробую рассказать в паре абзацев.

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

На самом деле сессии хранятся не обязательно в файлах. Например, cms Modx хранит их базе данных.
Но сейчас нам это не важно, главное, что сессии предоставляют удобный способ работать с данными, уникальными для пользователя.
Для нас сессия выглядит как обычный ассоциативный массив под названием $_SESSION, в разные поля которого можно записать хоть число, хоть строку, хоть сериализованный объект.

Roave/security-advisories

Пакет Roave security-advisories использует репозиторий Friends of PHP, чтобы ваш проект не зависел от любых пакетов с известными уязвимостями.

composer require roave/security-advisories:dev-master

Или можете загрузить свой файлcomposer.lock в Sensio Labs в качестве стандартной процедуры автоматической оценки на уязвимости, чтобы получать предупреждения о любых устаревших пакетах.

Vimeo/psalm

Psalm — инструмент статичного анализа, помогающий определять возможные баги в вашем коде. Хотя есть и другие хорошие инструменты (например, замечательные Phan и PHPStan), но если вам нужна поддержка PHP 5, то Psalm — один из лучших инструментов статичного анализа для PHP 5.4 .

Использовать Psalm просто:

# Version 1 doesn't exist yet, but it will one day:
composer require --dev vimeo/psalm:^0

# Only do this once:
vendor/bin/psalm --init

# Do this as often as you need:
vendor/bin/psalm

Если вы впервые применяете этот код к имеющейся базе данных, то увидите много красных отметок. Если вы не создаёте приложение масштаба WordPress, то маловероятно, что вам придётся совершить подвиг Геркулеса, чтобы пройти все эти тесты.

Вне зависимости от того, какой инструмент статичного анализа вы выбрали, рекомендуем внедрить его в рабочий процесс непрерывной интеграции (если это возможно), чтобы инструмент запускался после каждого изменения кода.

Xml-атаки (xxe, xpath-внедрения)

Есть две основные уязвимости, проявляющиеся в приложениях, которые много обрабатывают XML:

1. Внешние сущности XML (XXE).
2. XPath-внедрения.

XXE-атаки, помимо прочего, могут использоваться как стартовая площадка для эксплойтов локального/удалённого внедрения файлов.

Ранние версии Google Docs были уязвимы к XXE-атакам, но они мало известны за пределами бизнес-приложений, обрабатывающих большие объёмы XML.

Главное, что нужно сделать для защиты от XXE-атак:

libxml_disable_entity_loader(true);

XPath-внедрение очень похоже на SQL-внедрение, только здесь речь идёт об XML-документах.

К счастью, в PHP-экосистеме редко возникают ситуации, когда вводимые пользователями данные передаются в XPath-запросе.

К сожалению, это также означает, что лучшее доступное решение (для заранее скомпилированных и параметризованных XPath-запросов) в PHP-экосистеме отсутствует.

Рекомендуем использовать белые списки разрешённых символов для любых данных, имеющих отношение к XPath-запросам.

Архив обновлен 24.02.2022г.

Внимание:
Если вы используете данный скрипт на локальном сервере типа
DENWER XAMPP
, то не
стоит ждать писем на свой почтовый ящик. Письма лежат в заглушке
sendmail
. В
Denwer
вы их можете
найти по пути
Z:tmp!sendmail
открыть данные файлы вы сможете в любом почтовом клиенте.

Безопасное журналирование событий с помощью chronicle

Подробнее: Chronicle заставит задуматься, нужна ли вам технология блокчейна

Chronicle — криптографический журнал, обновляемый только путём добавления новых записей. Он основан на использующей хеш-цепочки структуре данных, свойства которой, безо всяких излишеств, привлекают многие компании в стан технологии «блокчейна».

Помимо более изощрённых способов применения такого журнала, Chronicle превосходно себя проявляет в SIEM, поскольку вы можете отправлять важные с точки зрения безопасности события в личный журнал, после чего они становятся неизменяемыми.

Если ваш Chronicle настроен на перекрёстную запись (cross-sign) суммарного хеша в другие экземпляры Chronicle и/или если есть другие экземпляры, сконфигурированные на репликацию содержимого вашего Chronicle, то атакующему будет крайне сложно подделать ваши журналы событий безопасности.

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

Для публикации данных в локальный Chronicle можно использовать любой API, совместимый с Sapient, но самое простое решение — Quill.

Версии php

Вкратце: ничего не поделаешь, но в 2022-м вы будете пользоваться PHP 7.2, а в начале 2022-го — планировать перейти на 7.3.

PHP 7.2 вышел 30 ноября 2022 г.

На момент написания статьи только PHP 7.1 и 7.2 активно поддерживаются разработчиками языка, а для PHP 5.6 и 7.0 ещё примерно год будут выходить патчи безопасности.

В некоторых ОС есть долговременная поддержка уже не поддерживаемых версий PHP, но это считается в целом порочной практикой. Например, бэкпортирование патчей безопасности без инкрементирования номеров версий затрудняет оценку системы безопасности только по версии PHP.

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

Взаимодействие с базами данных

Подробнее: Предотвращение SQL-внедрений в PHP-приложениях

Если вы сами пишете SQL-запросы, проверьте, что вы используете подготовленные выражения (prepared statements) и что любая предоставляемая сетью или файловой системой информация передаётся в виде параметров, а не конкатенируется в строку запроса. Также удостоверьтесь, что вы избегаете эмулированных подготовленных выражений.

Лучший выбор — EasyDB.

НЕ ДЕЛАЙТЕ ТАК:

Взаимосвязи документов

Веб-разработчики часто задают гиперссылкам атрибут target (например, target=”_blank” для открытия ссылки в новом окне). Но если вы не передаёте также тэг rel=”noopener”, то позволите целевой странице получить контроль над исходной страницей.

Не делайте так

Выбираем правильное хэширование

Идею хранения паролей нашли, то есть хранения не паролей, а их хэшей. А вот какой алгоритм хэширования выбрать?

Давайте посмотрим на то, что пробовали выше – простая функция md5. Алгоритма его расшифровки нет, но тем не менее md5 не рекомендуется для использования. Почему?

Помимо сложности самого алгоритма, есть и другой момент. Да, расшифровать пароль по хэшу нельзя, но его можно подобрать. Простым брутфорсом.
К тому же существуют многочисленные базы паролей md5, где всевозможные варианты хранятся тупо списком.
И подбор вашего пароля по известному хэшу займет столько времени, сколько понадобится для выполнения sql-запроса

    select password from passwords where hash='e10adc3949ba59abbe56e057f20f883e';

Конечно, вы сами не будете использовать пароль 123456, но как насчет ваших пользователей? Да, 123456 можно подобрать и руками, но в таком случае никакие алгоритмы не помогут.
Наша же задача максимально позаботиться о юзерах, которые выбирают пароли сложнее qwerty. Думаем дальше, гуглим.

Помимо md5 есть множество алгоритмов хэширования, sha256, sha512 и еще целая толпа. Их сложность выше, но это не отменяет опять-таки существования таблиц с готовыми паролями.
Нужно что-то хитрее.

Десериализация и внедрение php-объектов

Подробнее: Безопасная (де)сериализация в PHP

Если вы передаёте в unserialize() недоверенные данные, то напрашиваетесь на два варианта развития событий:

1. Внедрение PHP-объекта, который можно использовать для запуска POP-цепочки и срабатывания других уязвимостей из неправильно используемых объектов.
2. Повреждение памяти в самом интерпретаторе PHP.

Многие разработчики предпочитают использовать вместо этого JSON-сериализацию, что является заметным улучшением безопасности ПО. Но имейте в виду, что json_decode()уязвима для DDoS-атак посредством хеш-коллизий. К сожалению, полное решение проблемы хеш-DOS в PHP ещё предстоит найти.

Полностью защититься от этих атак поможет мигрирование с djb33 на Siphash с назначением 1 в качестве старшего бита для хеша строкового входного значения, 0 для целочисленного и с заранее запрошенным ключом, его предоставит CSPRNG.

К сожалению, создатели PHP не готовы частично пожертвовать производительностью, которой они добились в PHP 7, поэтому трудно убедить их отказаться от djb33 (очень быстрого, но небезопасного) в пользу SipHash (тоже быстрого, хотя и не как djb33, но куда более безопасного).

Поэтому лучше поступать так:

• Использовать JSON, это безопаснее unserialize().
• Там, где возможно, аутентифицируйте входные данные, прежде чем десериализовать их.
• Там, где нет возможности аутентифицировать JSON-строки, используйте строгое рейт лимиты и блокируйте IP-адреса для защиты от атаки повторением.

Заглушка для авторизации

Функции, связанные с авторизацией, будут лежать в отдельном файле и своем пространстве имен. Создадим файл auth.php в api/v1/common – там, где уже лежит helpers.php.
Если вы разбирали уроки админки, особенно третий, про серверную часть, то эти пути вам будут знакомы. Если у вас свой проект, то кладите auth.php куда удобно.
Главное, потом правильно указать пути.

Содержимое auth.php

Загрузка файлов

Подробнее: Как безопасно разрешать пользователям загружать файлы

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

Загружаемые файлы должны иметь атрибуты «только для чтения» или «только для чтения или записи» и никогда не быть исполняемыми.

Источники

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

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

Если вы работаете в компании, которая заинтересована в оценке соответствия требованиям (PCI-DSS, ISO 27001 и т. д.), можете нанять нас для аудита своего исходного кода. Мы работаем гораздо более дружественно к разработчикам, чем другие консультанты по безопасности.

Ниже — список источников от PHP-сообщества и сообщества по информационной безопасности.

• PHP: The Right Way — бесплатное руководство по современной PHP-разработке.
• Генератор SSL-конфигураций Mozilla.
• Let’s Encrypt — сертификационная компания, бесплатно предоставляющая TLS-сертификаты ради повышения безопасности интернета.
• Qualys SSL Labs предоставляет простой тестовый набор для TLS-конфигураций. Очень многие используют его для отладки своих наборов шифров и решения проблем с сертификатами, и не просто так: инструмент работает отлично.
• Security Headers умеет проверять, насколько хорош ваш сайт с точки зрения использования браузерных средств безопасности для защиты пользователей.
• Report-URI — замечательный бесплатный ресурс, поддерживающий инициативы по внедрению заголовков безопасности. Вам даётся Report-URI, который вы можете передавать браузерам пользователей, а те будут жаловаться Report-URI, если что-то сломается или обнаружится вектор XSS-атаки. Report-URI собирает все эти ошибки и помогает лучше отлаживать и сортировать статистику.
• The PHP Security Advent Calendar, созданный разработчиками RIPSTech.
• Snuffleupagus — PHP-модуль для улучшения безопасности приложений (и духовный наследник практически заброшенного Suhosin).
• PHP Delusions — сайт, посвящённый улучшению использования PHP. Многое высказано очень категорично, но из-за стремления автора к технической точности и ясности почитать стоит. Особенно тем, кто не очень хорошо разбирается во многих функциях PDO.
• Have I Been Pwned? помогает пользователям узнать, оказались ли их данные среди ранее украденной информации.

Как обойтись без шифрования. хэширование

Фокус в том, что не нужно хранить пароли в открытом виде, но и не нужно шифровать их с возможностью расшифровки. Пароли нужно хэшировать и в базе хранить не пароль, а его хэш.
Хитрым образом закодированную строку, которую нельзя расшифровать. Например, не password, а 5f4dcc3b5aa765d61d8327deb882cf99

Вы можете спросить, что это за хрень и как же сравнить пароль, введенный пользователем, с паролем, лежащим в базе. А нам и не нужно сравнивать пароли – достаточно сравнить их хэши.

Например, есть простая функция хэширования md5. Вот так она работает

Криптография общего назначения

Мы много писали на эту тему:

Для криптографии на уровне приложения всегда выбирайте библиотеку Sodium (libsodium). Если вам нужно поддерживать PHP ниже 7.2 (вплоть до 5.2.4), можете использовать sodium_compat и притвориться, что пользователи тоже применяют 7.2.

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

Межсайтовый скриптинг (xss)

Подробнее: Всё, что вам нужно знать о предотвращении межсайтового скриптинга в PHP

В идеальном мире предотвратить XSS было бы так же легко, как и SQL-внедрение. У нас был бы простой в использовании API для отделения структуры документа от его содержимого.

Мы это проходили

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

Начнем, как всегда, с формы. Вот ее разметка:

Несколько слов от автора

Проницательный читатель мог заметить, что мы много ссылаемся на собственные работы (статьи и open source проекты), но мы ссылаемся не только на свои работы.

Это неслучайно.

Наша компания с самого основания в начале 2022-го пишет библиотеки для обеспечения безопасности и участвует в повышении защищённости экосистемы PHP.

Мы много путешествуем, и наш инженер по безопасности (чьи недавние усилия по использованию более сильной криптографии в ядре PHP только что отразились в PHP 7.2), по его собственному признанию, не слишком силён в генерировании хайпа или интереса к своей работе. Наверняка вы не слышали и о половине инструментов или библиотек, созданных нами за эти годы.

Но мы не можем стать пионерами во всех направлениях, поэтому везде, где это возможно, связываемся с экспертами индустрии, которые, как нам кажется, больше ориентируются на общественное благо, чем на мелкий эгоизм. Поэтому большая часть раздела, посвящённого безопасности в браузере, снабжена ссылками на работы Скотта Хелме (Scott Helme) и компании. Он вложил много сил в то, чтобы эти новые возможности по обеспечению безопасности стали доступны и понятны разработчикам.

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

Обработчик с элементами ооп и бес субд

Вы не ослышались: сегодняшний скрипт авторизации на PHP будет без СУБД. Точнее, это сделано намеренно, чтобы акцентировать внимание на сессиях. А для обработчика мы создадим отдельный класс и наполним его специализированными функциями.

Все переменные сессии доступны через одноименный глобальный массив PHP $_SESSION. Для начала запускаем сессию и устанавливаем «правильную» кодировку:

Особые случаи

Вы получили представление, как в 2022-м нужно создавать защищённые PHP-приложения. Давайте теперь рассмотрим некоторые специфические случаи.

Проверяем работоспособность vue

Вроде бы, чего там может сломаться? Нам же практически не пришлось лезть в код vue, за исключением добавления кнопки Выйти в шапке админки.

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

    npm run build

Разработка защищённых api

Подробнее: С помощью Sapient закаливаем ваши PHP API

Разработка защищённых php-приложений

Если безопасность ПО для вас в новинку, можете начать с введения A Gentle Introduction to Application Security.

Многие специалисты по безопасности с самого начала обращают внимание разработчиков на ресурсы вроде OWASP Top 10. Но многие распространённые уязвимости можно считать особыми случаями одних и тех же высокоуровневых проблем (код/данные не разделены адекватно, ошибочная логика, небезопасная операционная среда, сломанные криптографические протоколы).

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

Рекомендуемые пакеты

Вне зависимости от того, что вы создаёте, наверняка эти зависимости будут вам полезны. Это в дополнение к тому, что рекомендует большинство PHP-разработчиков (PHPUnit, PHP-CS-Fixer и т. д.).

Создание форм регистрации и авторизации на php

<?php
    session_start();
    include('config.php');
    if (isset($_POST['register'])) {
        $username = $_POST['username'];
        $email = $_POST['email'];
        $password = $_POST['password'];
        $password_hash = password_hash($password, PASSWORD_BCRYPT);
        $query = $connection->prepare("SELECT * FROM users WHERE email=:email");
        $query->bindParam("email", $email, PDO::PARAM_STR);
        $query->execute();
        if ($query->rowCount() > 0) {
            echo '<p class="error">Этот адрес уже зарегистрирован!</p>';
        }
        if ($query->rowCount() == 0) {
            $query = $connection->prepare("INSERT INTO users(username,password,email) VALUES (:username,:password_hash,:email)");
            $query->bindParam("username", $username, PDO::PARAM_STR);
            $query->bindParam("password_hash", $password_hash, PDO::PARAM_STR);
            $query->bindParam("email", $email, PDO::PARAM_STR);
            $result = $query->execute();
            if ($result) {
                echo '<p class="success">Регистрация прошла успешно!</p>';
            } else {
                echo '<p class="error">Неверные данные!</p>';
            }
        }
    }
?>

Создание формы авторизации

Теперь перейдем непосредственно к самой авторизации. Создайте файл с названием mylogin.html со следующим содержанием:

Создание формы регистрации

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

Стандартная авторизация

Авторизация на сайте является необходимой функцией. С ее помощью владелец ресурса может попасть в административную панель и скорректировать работу систему, а контентщик – опубликовать новый материал.

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

Структура таблицы: bez_reg

--
-- Структура таблицы `bez_reg`
--

CREATE TABLE IF NOT EXISTS `bez_reg` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(200) NOT NULL,
  `pass` varchar(32) NOT NULL,
  `salt` varchar(32) NOT NULL,
  `active_hex` varchar(32) NOT NULL,
  `status` int(1) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

Управление зависимостями

Вкратце: используйте Composer.

Composer — это шедевральное решение по управлению зависимостями в PHP-экосистеме. В книге PHP: The Right Way целый раздел посвящён началу работы с Composer, очень рекомендуем его прочесть.

Если вы не пользуетесь Composer для управления зависимостями, то рано или поздно (надеюсь — поздно, но, скорее всего, рано) окажетесь в ситуации, когда одна из библиотек, от которой вы зависите, сильно устареет, а преступники начнут активно эксплуатировать уязвимости в старых версиях.

Важно: не забывайте обновлять свои зависимости по мере разработки ПО. К счастью, это можно сделать одной строкой:

composer update

Если вы делаете что-то особенное, требующее использования PHP-расширений (написанных на С), то вы не можете установить их с помощью Composer. Вам также потребуется PECL.

Файл reg_form.html

Так как регистрация пользователей у нас готова, самое время написать авторизацию. Создадим форму для авторизации
пользователей, далее напишем обработчик формы авторизации и на последок сделаем скрипт show.php который
будет показывать нам авторизированны мы в системе или нет.

Хеширование паролей

Подробнее: Как в 2022-м безопасно хранить пользовательские паролиБезопасное хранилище паролей раньше было темой активной дискуссии, но сегодня его просто реализовать, особенно в PHP:

$hash = password_hash($password, PASSWORD_DEFAULT);

if (password_verify($password, $hash)) {
    // Authenticated.
    if (password_needs_rehash($hash, PASSWORD_DEFAULT)) {
        // Rehash, update database.
    }
}

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

Что бы вы ни делали, не делайте так, как WordPress.

Если интересно: с PHP 5.5 по 7.2 алгоритмом по умолчанию является bcrypt. В будущем его могут заменить Argon2, победителем в Соревновании по хешированию паролей.

Если до этого вы не использовали API password_* и вам нужно мигрировать легаси-хеши, то сделайте это именно так. Многие компании, например Yahoo, поступили неправильно. Похоже, недавно причиной бага с iamroot у Apple стала некорректная реализация обновления легаси-хешей.

Целостность подресурсов

Однажды в будущем вы станете работать над проектом, использующим CDN для выгрузки традиционных Javascript/CSS-фреймворков и библиотек в центральное расположение. Неудивительно, что специалисты по безопасности предсказали очевидную проблему: если много сайтов используют CDN для предоставления части своего содержимого, то взлом CDN и подмена данных позволит внедрять произвольный код на тысячи (если не миллионы) сайтов.

Поэтому придумали целостность подресурсов (subresource integrity).

Целостность подресурсов (SRI) позволяет закреплять хеш содержимого файла, которое вам должна предоставить CDN. Текущая реализация SRI позволяет использовать только криптографические хеш-функции, поэтому злоумышленники не смогут сгенерировать вредоносные версии контента, приводящие к таким же хешам, как у оригинальных файлов.

Реальный пример: Bootstrap v4-alpha использует SRI в примере кода их CDN.

Шифрование с возможностью поиска

Подробнее: Building Searchable Encrypted Databases with PHP and SQL

Многим хочется иметь шифрованные базы данных с возможностью поиска, но считается, что их трудно реализовать. По ссылке выше вы найдёте статью, в которой мы последовательно ведём читателя по разработке такой БД. В частности:

1. Проектируем такую архитектуру, чтобы компрометация базы данных не позволила атакующему получить доступ к ключам шифрования.
2. Шифруем данные одним секретным ключом.
3. Создаём многочисленные индексы (с собственными различными секретными ключами) на основе HMAC или безопасного KDF со статической солью (например, Argon2).
4. По желанию: усекаем выходные данные шага 3, используем их в качестве Bloom-фильтра.
5. Используем выходные данные шагов 3 или 4 в запросах SELECT.
6. Расшифровываем результат.

На любом шаге вы можете идти на компромиссы в зависимости от того, что в вашем случае оправдано.

Вместо заключения

Проблемы с dev режимом во vue – это неприятный момент. Мы хотим и апишечку подергать, и все удобства vue-cli использовать. И на елку влезть, и ничего не ободрать.
Возможно, есть более изящный способ обойти эти проблемы в dev режиме, но я их пока не нашел. Поэтому приходится подпирать код лишними условиями.