Использование QueryString в качестве переключателя отладки?

Question

Сегодня я проводил рефакторинг некоторого кода в веб-приложении и наткнулся на что-то подобное в базовом классе для всех веб-страниц:

if (Request.QueryString["IgnoreValidation"] != null)
{
    if (Request.QueryString["IgnoreValidation"].ToUpper() == "TRUE")
    {
        SessionData.IgnoreValidation = true;
    }
}

Мне кажется, это очень плохая вещь ™, поэтому я немедленно удалил все следы этого флага из кода. С одной стороны, было несколько операторов if, которые были засорены повсюду, которые проверяли значение флага, что приводило к хаотичной и неясной логике. Во-вторых, я наткнулся на другой, более опасный флаг с именем «IgnoreCreditCardValidation». Вы можете догадаться, что это сделал ...

Затем я подумал об этом и вспомнил похожий пример из предыдущей работы. В коде приложения, продаваемого как «модуль защищенной аутентификации», был параметр QueryString, используемый для переопределения поведения по умолчанию, позволяя любому, кто его знает, обойти аутентификацию.

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

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

Спасибо!

Answer 1

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

Answer 2

Я иду против структуры и говорю строки запроса делают хорошие переключатели отладки.

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

Но для отладки отлично работают строки запросов. У нас есть несколько строк запросов, которые включают идентификаторы для нескольких объектов на наших страницах, поэтому мы можем быстро получить их без входа в производственную базу данных (конечно, не у всех есть доступ к Prod DB) или для проверки компонентов расчета. Вы просто должны быть осторожны и умны с ними.

Answer 3

Это оригинальный разработчик, который ленив, когда дело доходит до дизайна и тестирования.

Идеальным решением является отделение проверки подлинности или проверки подлинности кредитной карты и т. Д. От кода в отдельных библиотеках / службах и т. Д. Реальные версии могут быть заменены макетами для облегчения тестирования сайта. Услуги также могут быть протестированы независимо.

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

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

Answer 4

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

Answer 5

Я согласен с вами. Особенно, если модуль предназначен для обеспечения безопасности, это глупо иметь в релизной сборке (в отладочных сборках тоже не очень хорошая идея, но это может быть разумно). По сути, это безопасность -по-неизвестность.