# User context

An exception is easier to fix when you know who hit it.

## What is sent by default

If somebody is authenticated when the exception is thrown, the client attaches the user. With no other configuration that means the whole model, as `toArray()` gives it, which is almost certainly more than you want to store: names, email addresses, whatever else is on the row.

## Choosing what is sent

Implement `Larabugable` on the model and say exactly what LaraBug is given:

```php app/Models/User.php
use LaraBug\Concerns\Larabugable;

class User extends Authenticatable implements Larabugable
{
    public function toLarabug(): array
    {
        return [
            'id' => $this->id,
            'plan' => $this->plan?->name,
        ];
    }
}
```

An id and the one or two attributes that change how the application behaves are usually enough to reproduce a bug, and an id is not personal data in the way an email address is.

This is the recommended setup for any application that holds personal data. It is one method, and it turns the user block from "everything on the row" into "what we need".

## Not sending a user at all

Return an empty array from `toLarabug()`. The block is then present and empty rather than absent, which is the honest answer: somebody was signed in, and you chose not to record who.

## Guests

No authenticated user means no user block. The request, the route and the IP handling still apply, and those are covered under [filtering sensitive data](/docs/guides/filtering-sensitive-data).