Ошибка 404 symfony

В приложениях Symfony все ошибки рассматриваются как исключения Exception, независимо от того, являются ли они просто ошибкой 404 Not Found или фатальной ошибкой, вызванной возникновением некоторого исключения в вашем коде.

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

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

Страницы ошибок для production среды могут быть настроены по-разному в зависимости от ваших потребностей:

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

Как переопределить шаблон страницы ошибок по умолчанию?

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

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

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

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

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

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

templates/
└─ bundles/
   └─ TwigBundle/
      └─ Exception/
         ├─ error404.html.twig
         ├─ error403.html.twig
         └─ error.html.twig      # All other HTML errors (including 500)

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

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

{# templates/bundles/TwigBundle/Exception/error404.html.twig #}
{% extends 'base.html.twig' %}

{% block body %}
    <h1>Page not found</h1>

    <p>
        The requested page couldn't be located. Checkout for any URL
        misspelling or <a href="{{ path('homepage') }}">return to the homepage</a>.
    </p>
{% endblock %}

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

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

Тестирование страниц ошибок в режиме develop.

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

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

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

# config/routes/dev/framework.yaml
_errors:
    resource: '@FrameworkBundle/Resources/config/routing/errors.xml'
    prefix:   /_error

После добавления этого маршрута вы можете использовать подобные URL-адреса для предварительного просмотра страницы ошибки для заданного кода состояния в виде HTML или для заданного кода состояния и формата.

http://localhost/index.php/_error/{statusCode}
http://localhost/index.php/_error/{statusCode}.{format}

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

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

 composer require serializer

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

# src/App/Serializer/MyCustomProblemNormalizer.php
namespace AppSerializer;

use SymfonyComponentSerializerNormalizerNormalizerInterface;

class MyCustomProblemNormalizer implements NormalizerInterface
{
    public function normalize($exception, string $format = null, array $context = [])
    {
        return [
            'content' => 'This is my custom problem normalizer.',
            'exception'=> [
                'message' => $exception->getMessage(),
                'code' => $exception->getStatusCode(),
            ],
        ];
    }

    public function supportsNormalization($data, string $format = null)
    {
        return $data instanceof FlattenException;
    }
}

Переопределение стандартного ErrorController.

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

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

# config/packages/framework.yaml
framework:
    error_controller: AppControllerErrorController::showAction

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

• exception — Экземпляр FlattenException, созданный из обрабатываемого исключения.
• logger — Экземпляр DebugLoggerInterface, который может быть null в некоторых случаях.

Вместо создания нового контроллера исключений с нуля вы также можете расширить ExceptionController по умолчанию. В этом случае вы можете переопределить один или оба метода showAction() и findTemplate(). Последний находит шаблон для использования.

В случае расширения ExceptionController вы можете настроить сервис для передачи окружения Twig и флага отладки в конструктор.

# config/services.yaml
services:
    _defaults:
        # ... be sure autowiring is enabled
        autowire: true
    # ...

    AppControllerCustomExceptionController:
        public: true
        arguments:
            $debug: '%kernel.debug%'

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

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

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

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

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

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

With a Subscription, click any sentence in the script to jump to that part of the video!

Login
Subscribe

What should the structure of a 404 response from our API look like? It’s obvious: we’ll want to return that same API Problem JSON response format. We want to return this whenever anything goes wrong.

Planning the Response

Start by planning out how the 404 should look with a new test method — test404Exception. Let’s make a GET request to /api/programmers/fake and assert the easy part: that the status code is 404. We also know that we want the nice application/problem+json Content-Type header, so assert that too:

We know the JSON will at least have type and title properties. So what would be good values for those? This is a weird situation. Usually, type conveys what happened. But in this case, the 404 status code already says everything we need to. Using some type value like not_found would be fine, but totally redundant.

Look back at the Problem Details Spec. Under «Pre-Defined Problem Types», it says that if the status code is enough, you can set type to about:blank. And when you do this, it says that we should set title to whatever the standard text is for that status code. A 404 would be «Not Found».

Add this to the test: use $this->asserter()->assertResponsePropertyEquals() to assert that type is about:blank. And do this all again to assert that title is Not Found:

How 404’s Work

A 404 happens whenever we call $this->createNotFoundException() in a controller. If you hold cmd or ctrl and click that method, you’ll see that this is just a shortcut to throw a special NotFoundHttpException. And all of the other errors that might happen will ultimately just be different exceptions being thrown from different parts of our app.

The only thing that makes this exception special is that it extends that very-important HttpException class. That’s why throwing this causes a 404 response. But otherwise, it’s equally as exciting as any other exception.

Handling all Errors

In ApiExceptionSubscriber, we’re only handling ApiException’s so far. But if we handled all exceptions, we could turn everything into the nice format we want.

Reverse the logic on the if statement and set the $apiProblem variable inside:

Add an else. In all other cases, we’ll need to create the ApiProblem ourselves. The first thing we need to figure out is what status code this exception should have. Create a $statusCode variable. Here, check if $e is an instanceof HttpExceptionInterface: that special interface that lets an exception control its status code. So if it is, set the status code to $e->getStatusCode(). Otherwise, we have to assume that it’s 500:

Now use this to create an ApiProblem: $apiProblem = new ApiProblem() and pass it the $statusCode:

For the type argument, we could pass about:blank — that is what we want. But then in ApiProblem, we’ll need a constant for this, and that constant will need to be mapped to a title. But we actually want the title to be dynamic based on whatever the status code is: 404 is «Not Found», 403 is «Forbidden», etc. So, don’t pass anything for the type argument. Let’s handle all of this logic inside ApiProblem itself.

In there, start by making the $type argument optional:

And if $type is exactly null, then set it to about:blank. Make sure the $this->type = $type assignment happens after all of this:

For $title, we just need a map from the status code to its official description. Go to Navigate->Class — that’s cmd+o on a Mac. Look for Response and open the one inside HttpFoundation. It has a really handy public $statusTexts map that’s exactly what we want:

Set the $title variable — but use some if logic in case we have some weird status code for some reason. If it is in the $statusTexts array, use it. Otherwise, well, this is kind of a weird situation. Use Unknown Status Code with a frowny face:

If the $type is set — we’re in the normal case. Move the check up there and add $title = self::$titles[$type]. After everything, assign $this->title = $title:

Now the code we wrote in ApiExceptionSubscriber should work: a missing $type tells ApiProblem to use all the about:blank stuff. Time to try this: copy the test method name, then run:

./bin/phpunit -c app --filter test404Exception

Aaaand that’s green. It’s so nice when things work.

What we just did is huge. If a 404 exception is thrown anywhere in the system, it’ll map to the nice Api Problem format we want. In fact, if any exception is thrown it ends up with that format. So if your database blows, an exception is thrown. Sure, that’ll map to a 500 status code, but the JSON format will be just like every other error.