Проверьте что используется шаблон core 404 html

Как протестировать 404 не найден с Django Testing framework?

Я пытаюсь автоматизировать тестирование 404 страниц с помощью платформы тестирования Django 1.4.

если я распечатаю 127.0.0.1:8000/something/really/weird/ в адресной строке браузера с запущенным сервером разработки я вижу страницу 404 с правильным статусом «404 не найден» (как показывает firebug).

но если я пытаюсь использовать этот код для проверки:

тест терпит неудачу с этим выходом:

Я серьезно удивлен, получив 200 код здесь. Кто-нибудь знает, почему на земле это происходит?

обновление:

здесь лежит urls.py:http://pastebin.com/DikAVa8T и фактический неудачный тест:

все происходит в проекте https://github.com/gbezyuk/django-app-skeleton

2 ответов

проблема в том, что ваш класс ViewFor404 возвращает код состояния 200. Посмотрите на определение TemplateView Джанго:

Так что все ваши класса является render_to_response, который генерирует ‘200’ ответ.

Если вам нужно переопределить обработчик 404, вы должны сделать что-то вроде этого в представлении:

(Я не знаю эквивалента в представлениях на основе классов)

или еще лучше, вы можете избежать настройки посмотреть? К настроить отображение 404, вы можете просто создать 404.html-шаблон (в шаблонах/ каталоге вашего сайта), и он будет подхвачен средством просмотра ошибок Django.

127.0.0.1:8000/something/really/weird/ is /something/really/weird/ в пути относительно корня,не

Проверьте что используется шаблон core 404 html

Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core

С помощью двух секций customErrors и httpErrors в файле конфигурации мы можем задать в ASP.NET MVC 5 обработку статусных кодов ошибок.

Секция customErrors в web.config позволяет задать собственные страницы ошибок для различных статусных кодов HTTP. Правда, применение этой секции имеет ограничения.

Вначале добавим в проект свои страницы ошибок. Например, для обработки ошибки 404 добавим в корень проекта файл 404.html :

Подобным образом добавим файлы и для других ошибок.

Далее найдем в файле конфигурации web.config секцию system.web и поместим в нее подсекцию customErrors (если эта подсекция уже есть, изменим ее):

Внутри секции customErrors помещаются элементы error , каждый из которых задает код ошибки (атрибут statusCode ) и страницу переадресации при ошибке (атрибут redirect )

Если мы сейчас запустим приложение и обратимся к несуществующему ресурсу, то нам отобразится наша страница с ошибкой:

Однако при такой переадресации мы сталкиваемся с рядом проблем. Во-первых, в качестве адреса используется не оригинальный путь, к которому идет обращение, а 404.html. То есть вместо строки запроса /Home/Some , мы получаем /404.html?aspxerrorpath=/Home/Some . Во-вторых, при отдаче ответа клиент получает статусный код 200, то есть запрос успешно обработан, вместо кода 404.

Чтобы решить первую проблему, добавим к определению секции атрибут redirectMode=»ResponseRewrite» :

Теперь страницу с ошибкой можно будет увидеть напрямую по запрошенному пути. Однако клиенту все равно будут отдаваться статусный код 200.

Более того у нас есть еще и другая проблема. Если мы напрямую возвратим из метода контроллера статусный код ошибки, то этот код никак не будет обрабатываться, и настройки в customErrors на него не подействуют. Например:

При обращении к нему мы получим стандартное сообщение об ошибке:

И для решения возникших проблем нам надо использовать не customErrors , а элемент httpErrors .

Вначале для обработки ошибок добавим в приложение новый контроллер ErrorController:

Добавим представление для метода NotFound:

Подобным образом добавим представление и для других методов.

Далее добавим элемент httpErrors . Этот элемент помещается внутрь секции system.webServer . Если этой секции внутри web.config нет, то ее можно добавить. А узел customErrors мы можем удалить или закомментировать:

Элемент httpErrors имеет ряд настроек. Чтобы протестировать настройки локально, устанавливается атрибут errorMode=»Custom» . Если тестирование необязательно, и приложение уже развернуто для использования, то можно установить значение errorMode=»DetailedLocalOnly» .

Значение existingResponse=»Replace» позволит отобразить ошибку по оригинальному запрошенному пути без переадресации.

Внутри элемента httpErrors с помощью отдельных элементов error устанавливается обработка ошибок. Атрибут statusCode задает статусный код, атрибут path — адрес url, который будет вызываться, а атрибут responseMode указывает, как будет обрабатываться ответ вызванному url. Атрибут responseMode может принимать три значения:

ExecuteURL : производит рендеринг ответа полученного при вызове адреса url из атрибута path

Redirect : выполняет переадресацию со статусным кодом 302

File : рассматривает адрес url из атрибута path как статическую страницу и использует ее в качестве ответа

Настройки элемента httpErrors могут наследоваться с других уровней, например, от файла конфигурации machine.config . И чтобы удалить все унаследованные настройки, применяется элемент <clear /> . Чтобы удалить настройки для отдельных ошибок, применяется элемент <remove /> :

И теперь, если мы запустим приложение и обратимся по несуществующему пути или к методу, который возвращает статусный код 404, то у нас отобразится ответ от метода NotFound контроллера ErrorController:

Установка атрибута responseMode=»File» позволяет использовать в качестве ответа статические файлы. Например, используем ранее определенные файлы ошибок:

Как настроить страницы ошибок

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

В окружении разработки, Symfony ловит все исключения и отображаеть специальную страницу исключений со множеством информации по отладке, чтобы помочь вам быстро обнаружить основную проблему:

Так как эти страницы содержат много чувствительной внутренней информации, Symfony не будет отображать её в окружении производства. Вместо этого, она покажет простую и общую ошибку страница ошибки:

Страницы ошибок в окружении производства можно настроить разными способами, в зависимости от ваших потребностей:

1. Если вы просто хотите изменить содержание и стили страниц ошибок так, чтобы они совпадали с остальным вашим приложением, переопределите шаблоны ошибок по умолчанию ;
2. Если вы хотите изменить содержание вывода ошибки не в HTML, создайте новый нормализатор ;
3. Если вы также хотите настроить логику, используемую Symfony для генерирования ваших страниц ошибок, то переопределите контроллер ошибок по умолчанию ;
4. Если вам нужен полный контроль над работой с исключениями, выполните вашу собственную логику — используйте событие the kernel.exception .

Переопределение шаблонов ошибок по умолчанию

Вы можете использовать встроенное средство отображения ошибок Twig, чтобы переопределять шаблоны ошибок по умолчанию. Для этого должны быть установлены как TwigBundle, так и TwigBridge. Выполните эту команду, чтобы убедиться, что они оба установлены:

Когда загружается страница ошибки, для отображения шаблона twig и демонастрации пользователю, используется TwigErrorRenderer.

Этот отображатель использует статус-код HTTP, формат запроса и следующую логику, чтобы определить имя файла шаблона:

1. Ищет шаблон для заданного статус-кода (вроде error500.html.twig );
2. Если предыдущий шаблон не существует, отбросьте статус-код и ищет общий шаблон ошибок ( error.html.twig ).

Чтобы переопределить эти шаблоны, просто положитесь на стандартный метод Symfony для пеоепределения шаблонов, живущих внутри пакета: поместите их в каталоге templates/bundles/TwigBundle/Exception/ .

Типичный проект, возвращающий страницы HTML и JSON, может выглядеть так:

Пример шаблона ошибки 404

Чтобы переопределить шаблон ошибки 404 для HTML-страниц, создайте новый шаблон error404.html.twig , находящийся в templates/bundles/TwigBundle/Exception/ :

Если они вам понадобятся, TwigErrorRenderer передаёт некоторую информацию в шаблон ошибок через переменные status_code и status_text , которые хранят HTTP статус-код и сообщение соотвественно.

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

Кроме этого у вас есть доступ к Исключениям с помощью exception , который, к примеру, позволяет вам выводить отслеживание стека, используя << exception.traceAsString >> , или получить доступ к любому другому методу объекта. Однако будьте аккуратны, так как это с большой вероятностью может обнажить кофиденциальную информацию.

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

Безопасность и страницы 404

В связи с порядком, в котором загружаются маршрутизация и безопасность, конфиденциальна информация не будет доступна на ваших страницах 404. Это означает, что будет казаться, что ваш пользователь не залогинен в систему на странице 404 (это будет работать при тестировании, но не в производстве).

Тестирование страниц ошибок во время разработки

В то время, как вы находитесь в окружении разработки, Symfony отображает большую страницу исключений вместо вашей новой блестящей страницы ошибок. Так как вам увидеть, как она выглядит изнутри и отладить её?

К счастью, ExceptionController по умолчанию разрешает вам предпросмотр вашей страницы ошибки во время разработки.

Чтобы использовать эту функцию, вам загрузить специальные маршруты, предоставленные TwigBundle (если приложение использует Symfony Flex, то они загружаются автоматически при установке symfony/framework-bundle ):

• YAML
• XML
• PHP

C добавлением этого маршрута, вы можете использовать такие URL для предпросмотра страницы ошибки для заданного статус-кода в виде HTML или для заданного статус-кода и формата (вам может понадобиться заменить http://localhost/ на хостинг, используемый в ваших локальных настройках):

• http://localhost/_error/ для HTML
• http://localhost/_error/. для любого другого формата

Переопределение вывода ошибок для не-HTML форматов

Чтобы переопределить не-HTML вывод ошибки, необходимо установить компонент Serializer.

Компонент Serializer имеет встроенный нормализатор FlattenException (ProblemNormalizer) и кодировщики JSON/XML/CSV/YAML. Когда ваше приложение вызывает исключение, Symfony может вывести его в один из этих форматов. Если вы хоите изменить содержание вывода, создайте Нормализатор, который поддерживает ввод FlattenException :

Переопределение ExceptionController по умолчаию

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

Чтобы сделать это, просто создайте новый контролер где угодно в вашем приложении, и установите опцию конфигурации framework.error_controller , чтобы указать на неё:

• YAML
• XML
• PHP

Класс ExceptionListener, используемый TwigBundle в качестве слушателя события kernel.exception , создаёт запрос, который будет развёрнут в вашем контроллере. В дополнение, вашему контроллеру будут переданы два параметра:

exception Обработка первоначального экземпляра Throwable. logger Экемпляр DebugLoggerInterface, который может в некоторых случаях быть null .

Предпросмотр страницы ошибки также работает с вашими собственными контроллерами, нвстроенными как угодно.

Работа с событием kernel.exception

Когда вызывается исключение, класс HttpKernel ловит его и развёртывает событие kernel.exception . Это даёт вам возможность конвертировать исключение в Response несколькими разными способами.

Работа с этим событием на самом деле значительн более мощная, чем объяснялось раньше, но также требует тщательного понимания внутренних процессов Symfony. Представьте, что ваш код вызывает специальные исключения с конкретным значением в вашем домене приложения.

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

Если ваш слушатель вызывает setResponse() в событии ExceptionEvent, распространение будет остановлено и клиенту будет отправлен ответ.

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

Смотрите код класса ExceptionListener для реального примера продвинутого слушателя такого типа. Этот слушатель обрабатывает различные исключения, связанные с безопасностью, которые вызываются в вашем приложении (как AccessDeniedException) и предпринимает действия вроде перенаправления пользователей на страницу входа, выполняет их вход в систему и др.

Symfony is a trademark of Symfony SAS. Переклад — Playtini. UA RU RU EN

Проверьте что используется шаблон core 404 html

Unittest в Django:

Протестировал модели приложения posts в Yatube.

Добавил в классы Post и Group метод str (если его ещё нет):

• для класса Post — первые пятнадцать символов поста: post.text[:15];
• для класса Group — название группы.

Протестировал, правильно ли отображается значение поля str в объектах моделей.

Проверка доступности страниц и названия шаблонов приложения Posts проекта Yatube.

Проверка должна учитывать права доступа.

Проверьте, что запрос к несуществующей странице вернёт ошибку 404.

Проверка namespase:name и шаблонов

Тесты, проверяющие, что во view-функциях используются правильные html-шаблоны.

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

Дополнительная проверка при создании поста

Проверил, что если при создании поста указать группу, то этот пост появляется:

• на главной странице сайта,
• на странице выбранной группы,
• в профайле пользователя.

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