This will cause the right error (HTTP 401) to be thrown whenever
we're checking for a specific permission, but the user is not even
logged in. Authenticated users will still get HTTP 403.
HTTP 401 should be used when logging in (i.e. authenticating) would make
a difference; HTTP 403 is reserved for requests that fail because the
already authenticated user is not authorized (i.e. lacking permissions)
to do something.
...not based on status code.
To simplify this logic, we now use the same error "type" both when
routes are not found and specific models are not found. One exception is
ours, one is from Laravel, but for the purposes of error handling they
should be treated the same.
Fixesflarum/core#1641.
The error handling middleware now expects an array of reporters.
Extensions can register new reporters in the container like this:
use Flarum\Foundation\ErrorHandling\Reporter;
$container->tag(NewReporter::class, Reporter::class);
Note that this is just an implementation detail and will be hidden
behind an extender.
This separates the error registry (mapping exception types to status
codes) from actual handling (the middleware) as well as error formatting
(Whoops, pretty error pages or JSON-API?) and reporting (log? Sentry?).
The components can be reused in different places (e.g. the API client
and the error handler middleware both need the registry to understand
all the exceptions Flarum knows how to handle), while still allowing to
change only the parts that need to change (the API stack always uses the
JSON-API formatter, and the forum stack switches between Whoops and
pretty error pages based on debug mode).
Finally, this paves the way for some planned features and extensibility:
- A console error handler can build on top of the registry.
- Extensions can register new exceptions and how to handle them.
- Extensions can change how we report exceptions (e.g. Sentry).
- We can build more pretty error pages, even different ones for
exceptions having the same status code.
This reverts commit f8061bbca1.
We will keep this fallback in place, to avoid unnecessary breakage of
backwards compatibility for extension authors.
Removal is planned for the final 0.1 release.
