Монитор качества - позволяет решить задачу обеспечения прозрачного и гибкого процесса сдачи веб-проекта клиенту, повышая уровень гарантированного результата и снижая общие риски. О мониторе качества написано много: - Учебный курс - Статья на ХабреНо ни где нет отзывов и пожеланий о данной разработке (или я не нашел). В данном посте напишу свое мнение о данном модуле. [spoiler] Данный пост буду периодически дописывать по мере поступления пожеланий. В нашей компании мы стараемся делать качественные сайты, поэтому выходу "Монитору качества" обрадовались с начала, но по мере сдачи тестов, проверяется избыточное количество параметров, на что уходит просто гигантское количество времени. Плюс например в редакции стар нет модуля "Проактивная защита", а проверки по нему в тестах есть. Зачем? И так монитор качества содержит 65 тестов!!! Не много ли? Из них обязательных 26 и только 12 проходят автоматически.
В обязательных есть тест: Настроены политики безопасности по работе с БД
Для соединения с базой данных на хостинге используется сильный пароль, настроены необходимые проекту привилегии для работы с базой данных (работа не под root).
По мимо того, что пароль к БД должен быть в разных регистрах, содержать цифры и спец. символы, так же пароль должен ОБЯЗАТЕЛЬНО содержать еще и знаки препинания!!! Без знаков препинания тест не пройти. Уважаемые разработчики, пожелание: "Уберите из проверки знаки препинания". Достаточно и того, что пароль содержит цифры, буквы и спец. символы. Знаки препинания это уже перебор.
Хотелось, что бы монитор производительности проверял наличие: - favicon.ico - robots.txt - 404.php у нас часто разработчики просто забывают об этих файлах, а на качество проектов это тоже влияет.
Было еще куча вопросов, но по мере сдачи новых проектов по монитору качества буду отписываться сюда.
А вот еще, в тестах пункт "Сдача проекта"
- Введена информация об интеграторе решения - Введена информация о техподдержке проекта
Тесты нужные, но как это все внести в проект не ясно. Есть предложение: Разработайте гаджет для рабочего стола, где разработчик укажет свои данные и информацию о тех. поддержке. Многие разработчики вероятно и не знают о файлах: this_site_logo.php this_site_support.php Может стоит дать описание про эти файлы. У себя мы разработали шаблон, который содержит уже оптимизированный под SEO htaccess, robots.txt + служебные файлы и гаджет "Информация о разработчике". У нас это выглядит так:
Если кому есть что добавить по модулю, то комментируйте, по обсуждаем.
Плюс например в редакции стар нет модуля "Проактивная защита", а проверки по нему в тестах есть. Зачем?
На тот момент, не было механизма вариации наборов обязательных тестов в зависимости от определенных условий. Сейчас этот механизм есть и внедрен в монитор качества для Маркетплэйса. Позже будет внедрен в "коробочный" монитор качества.
По остальным вопросам ваша позиция понятна. Будем обсуждать пожелания и вносить корректировки.
Можете раскрыть свою мысль о необходимости данной проверки? Не думаю, что это столь необходимо из коробки и в некоторых случаях даже вредно. Это скорее частный случай, на который вы всегда можете написать свой тест и включать его в чеклист своих клиентов(рассказав им о мерах предосторожности). Лично я, не рекомендовал бы использовать установку пароля для директории с помощью htpasswd. Посудите сами, это куда менее эффективное средство нежели ограничение доступа по IP или OTP, зато "замыливает" взгляд пользователю в последствии чего на него с большей вероятностью успеха можно произвести фишинг нападение используя Basic Authentication
А вот и сказка: один наш клиент ввел у себя личные кабинеты, видимо плохо разобравшись с правами доступа дал всем по максимуму к определенным ИБ и соотв. все посетители сайта получили доступ к админке с очень жирными правами на ИБ. Когда мы это заметили было уже поздно, благо есть бекапы. Можно конечно сказать сам виноват и т.п. полностью согласен, НО если бы стояла защита через htpasswd этого можно было избежать.
Лично я, не рекомендовал бы использовать установку пароля для директории с помощью htpasswd. Посудите сами, это куда менее эффективное средство нежели ограничение доступа по IP или OTP
Я не спорю, что это эффективно, НО некоторые разработчики даже пароль с 123456 забывают поменять при сдаче проекта. Сам лично ламонул сайт с логином admin и паролем qwerty. <skj интересно как партнер реализовал нужный мне функционал. Да и вы проведите опрос среди клиентов, кто знает, что есть защита по IP или OTP, а заодно про разграничение прав доступа спросите, многие даже и не догадываются, что можно делать разграничение прав доступа. Не многие в договорах прописывают разделение ролей на сайте при разработке, сдал сайт получил акты и досвидос
Вашу мысль понял:) но в вашей же присказке, авторы статьи солидарны с моим мнением:
На сайте Московского кредитного банка защита реализована на базе сервера, через .htpasswd .... По нашему мнению до сайта банка необходимо закрывать доступ извне и блокировать на уровне ip.
На счет сказки - этой ситуации можно было бы избежать ограничившись контролем по IP;) без всяких .htpasswd
некоторые разработчики даже пароль с 123456 забывают поменять при сдаче проекта.
Увы они с такой же легкостью могут распространять и одинаковый .htpasswd для всех своих проектов, со словами "замените потом change_me на нормальный пароль"
Главная мысль, которую я хотел донести - закрытие админки средствами .htpasswd это частный случай, который по моему мнению еще и не всегда уместен, поэтому вносить подобный тест (тем самым рекомендовав использовать этот метод) в чеклист из коробки я считаю излишним.
На счет поднятия уровня секьюрной сознательности разработчиков и клиентов, вы в целом правы. Его обязательно нужно повышать и мы думаем над решением, главное понять каков формат будет оптимальным.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».