-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exceptions are too public #13
Comments
Yeah, that would make sense .... The best option IMO is to put this logic inside the exception apiproblem: An other option is to add an exception transformation that does this job. Care to create a PR? |
Sorry for the delay @chekalsky and thanks for picking up the PR. I feel the same way about the PR and am going to decline it in a moment. You can create a new transformer and specify a good priority for it. <?php
use Phpro\ApiProblem\ApiProblemInterface;
use Phpro\ApiProblem\Http\ExceptionApiProblem;
use Phpro\ApiProblemBundle\Transformer\ExceptionTransformerInterface;
class PublicExceptionTransformer implements ExceptionTransformerInterface
{
public function __constuct(
private string ... $publicExceptionClasses
) {
}
public function transform(\Throwable $exception): ApiProblemInterface
{
$exceptionClass = get_class($exception);
if (in_array($exceptionClass, $this->publicExceptionClasses, true)) {
return new ExceptionApiProblem($exception);
}
// We could add a constructor variable to overwrite the message or add a withDetails() immutable method.
return new ExceptionApiProblem($exception, $exceptionClass);
}
public function accepts(\Throwable $exception): bool
{
return true;
}
} (You could make the code even smarter and specify a We could accept a PR for a default implementation of this listener. What do you think? |
i think this feature must depend with env - dev (more detailed) prod (hide trace and other sensitive information) |
I am concerned with random exception messages being revealed in the details field by default.
For example, today I've met Symfony's exception was thrown by internal logic of Translations engine with the text
Unable to write to the "/var/task/var/cache/lambda/translations" directory.
which reveals the internal structure of the project (and the fact project uses Symfony) which could be considered as a security breach.My proposition is to not show exception's message in
details
field by default in production environment.The text was updated successfully, but these errors were encountered: