Ну даже если это просто "моветон" все равно правильно, что он это обратил внимание.
А потом CSRF токен он не всегда "на страницу". Вполне себе популярное решение токен на сессию (Laravel, Symfony, Битрикс, Django....). Менять токен на каждом запросе, т.е. это уже на уровне фреймворка заставлять пользователя обыгрывать связанные с этим ситуации. (spa в нескольких вкладках, как пример). OWASP тоже как бы считает нормальным токен на сессию.
Да, пожалуй согласен, что выбрал не самое лучшее решение. Подумаю. Скорее тут лучше сделать конфигурабельным. И по умолчанию оставить как сейчас (логика в том, что это не требует доп. действий, ведь если сделать по дням, а пользователь не дочитает доку и не поставит, как пример, очистку на крон, то однажды лог может съесть все дисковое пространство... (хм кстати, пожалуй об этом надо мне подумать :) )
Я сейчас вижу там с filter.
<loc>https://permedcom.ru/catalog/stomatologiya/ortopantomografy/filter/manufacturer-is-sirona%20/</loc>
Nikita4404 кстати обратите внимание в конкретно этом случае %20 в URL - у вас там пробел есть мусорный
т.е. возможно в инфоблоке 31 сейчас у элементов настроен шаблон /catalog/#SECTION_CODE_PATH#/filter/#ELEMENT_CODE#/ - filter вместо tag
Лучше вам обратиться к программисту. На данный момент вы даже проблему описываете явно не правильно.
Я так понимаю у вас реализован функционал теговых страниц. Это не штатный механизм.
Как я понял из описания. У вас настройка теговых страниц находится в отдельном инфоблоке с ИД 31. В сайтмап ни когда не попадают URL настроенные через URL умного фильтра. (тут даже трудно представить сколько займут дискового пространства такие сайтмапы если сформировать. Представьте каталог имеющий тысячу свойств и сколько будет в нем комбинаций? (так для примера кодовый замок 4 цифры от 0 -9 имеет 10000 комбинаций :) а если добавить еещ в каждую позицию кроме цифр букву А то вариантов 14641 )
Далее уже важно как в реальности реализовали у вас генерацию url. Тут надо смотреть в инфоблоке посадочных страниц шаблон URL элементов. т.е. там должно быть что то типа (и это только если реализовано как я предполагаю - но могут быть и варианты)
/catalog/#SECTION_CODE_PATH#/tag/#ELEMENT_CODE#/
Но в этом варианте есть тонкость: подозреваю у вас частенько может "слетать" роутинг из-за изменений в urlrewrite.php. т.к. в этом случае у вас получится в нем шаблон одинаковый с шаблоном маршрута каталога.
В общем как итог: у вас точно НЕ стандартное решение. Т.е. тут надо смотреть конкретно ваш проект и разбираться как реализован этот функционал. Посмотрите в списке установленных модулей (
Не совсем понимаю сути претензии :) Полагаешь что на этот момент не стоило обращать внимания? Сам же пишешь, что "моветон". Имхо логично.
Это вообще не относится ни как к этой оценке . Это уже мое решение. В оценке лишь про гонку указано. что действительно может быть при таком подходе. Но я сознательно забил на это еще когда принимал решение.
Тут суть в моем таком решении. Да можно по дням, можно логротейт настроить. Если честно пока не решил на 100% как в конечном итоге хочу видеть. У каждого подхода есть свои недостатки. по дням у меня тоже были на проектах :). Тут решил так. Все же я сомневаюсь, что завтра гиганты индустрии начнут писать хайлоад проекты на моем фреймворке :) Думаю для данного этапа развития фреймворка решение правильное (не надо парится и знать что надо настроить логротейт или скрипит на крон.... (со скриптами вообще глубже буду продумывать когда буду реализовывать cli сторону фреймворка. вполне возможно там и про чистку/ротацию логов подумаю и прочие "чистки")
Ну тут надо уже искать. я тогда в другой ветке это делал и ее всю схлопнул в один киммит. ну вот маленький пример из отчета
2. Information Disclosure — ExceptionMiddleware отдаёт тексты исключений клиенту (CRITICAL) Файл: src/Middleware/ExceptionMiddleware.php return $this->buildResponse($exception->getMessage()) ->setStatus(ResponseStatus::INTERNAL_SERVER_ERROR); Текст любого исключения (включая \Throwable) напрямую возвращается в HTTP-ответ. Это раскрывает: - Пути файловой системы (Unable to open '/var/www/app/var/log/error.log') - Имена таблиц/колонок БД из будущих SQL-ошибок - Внутренние имена классов и структуру приложения - Потенциально — строки подключения и учётные данные из PDO-исключений Комментарий в коде говорит «фильтрация — ответственность разработчика», но это должно быть безопасным по умолчанию. 3. CSRF-токен в GET-параметрах (HIGH) Файл: src/Middleware/CsrfMiddleware.php $tokenFromRequest = trim( $request->get->getString(self::CSRF_TOKEN_NAME, '') // ← GET параметр! ?: $request->post->getString(self::CSRF_TOKEN_NAME, '') ?: $request->headers->getString(self::CSRF_TOKEN_HEADER, ''), ); CSRF-токен принимается через GET-параметры. Это означает: - Токен попадёт в URL (?csrf_token=abc123...), а значит: - В логи веб-сервера (access.log) - В заголовок Referer при переходе по ссылкам - В историю браузера - В логи прокси-серверов - Это фактически обнуляет CSRF-защиту, так как токен может быть легко перехвачен 8. Ротация логов — гонка и перезапись (MEDIUM) Файл: src/Logging/Handlers/StreamHandler.php if (file_exists($stream) && filesize($stream) > $maxFileSize) { rename($stream, $stream . '.old'); // ← хранится только 1 архив } - Race condition: между file_exists/filesize и rename другой процесс может записать в файл - Хранится только один архивный файл (.old), предыдущий архив удаляется без предупреждения — потеря логов в production - Нет блокировки файла при записи (fwrite без flock) — возможна перемешивание строк логов при конкурентных запросах
Каким образом? С онлайн моделью?
