Laravel-Exceptions: Whoops page when AuthenticationException is thrown in laravel 5.3

Just going to leave a comment for people experiencing this issue.

A temporal fix would be to update your app/Exceptions/Handler.php render method like so:

public function render($request, Exception $exception)
{
   if ($exception instanceof AuthenticationException) {
       return $this->unauthenticated($request, $exception);
   }

   return parent::render($request, $exception);
}

Use displayers properly. But how ? You’ve never told us how to do it properly is but you always ask us to do it properly. This package is great and I know it’s flexible, I just confuse how to do it right but you never give us an answer 😦

You write a displayer that implements https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/src/Displayers/DisplayerInterface.php, and then register it in the config file: https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/config/exceptions.php#L48.

The higher up it is, the earlier it’s tried out. The first one that passes the filters as defined in https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/config/exceptions.php#L69 will be used.

From this description, we can see that the debug displayer is always run if in debug, ahead of everything else. If you don’t want this, you need to move an existing displayer above it, or write your own, and put it above it in the config file.

I intentionally don’t spoon feed everything because I want to encourage people to read the whole codebase (and the tests!), and think for themselves, however, I do agree more pointers would be useful for people - I just didn’t write any due to lack of time.

Hey @GrahamCampbell, Could you just suggest a sample way to change the displayers priorities to get that work ? I have no idea about changing that array to make it work 😦

This issue can be resolved by:

public function render($request, Exception $exception)
    {
        if ($exception instanceof AuthenticationException) {
           return $this->unauthenticated($request, $exception);
        }

        if ($this->isHttpException($exception)) {
            return $this->renderHttpException($exception);
        }

        if (config('app.debug') && \App::isLocal()) {
            return $this->renderExceptionWithWhoops($exception);
        }

        return parent::render($request, $exception);
    }

Thanks.

This is very inconvenient and breaks app functionality. This is something that needs to be included out of the box. I’m actually moving to use filp/whoops directly because of this issues and overcomplicated approach.

this is a continuation of @scrubmx to fix the validation issue aswell for

The given data failed to pass validation

// add to the top of file
use Illuminate\Validation\ValidationException;

// ...

public function render($request, Exception $exception)
{
   if ($exception instanceof AuthenticationException) {
       return $this->unauthenticated($request, $exception);
   } elseif ($exception instanceof ValidationException) {
       return $this->convertValidationExceptionToResponse($exception, $request);
   }

   return parent::render($request, $exception);
}

am not sure if this issue was also in the 5.2 version of the package but its really focken annoying.

from what i understand that the purpose of the package is to add extra flexibility/features over the original ExceptionHandler and if anything was taken away it should be documented so the user dont go in rounds for 2-3 hours just because he/she decided to use this rather than using the included one.

I’ll take a closer look soon when I have some more time. 😃

You can get whoops yourself just by copying the debug displayer code into your app if you have no interest in using the displayer and filter design pattern enforced in this package (i have no idea what the actual name of this pattern is since I can up with it independently, but I’m sure someone has named it somewhere).

https://github.com/GrahamCampbell/Laravel-Exceptions/blob/master/src/Displayers/DebugDisplayer.php

Is there a way to configure the priorities for this to work? Or is the only option doing as @scrubmx suggests above?

Would it be a good idea for it to work out of the box? I came into this issue yesterday too, as by default Laravel has moved this into the Exception\Handler. Previously my understanding of this package would be that I could simply replace the default handler and it work without causing any other issues, but now means making a change somewhere for it to not break default behaviour