rodrigopedra
commented
5 years ago Sincere question here: Why isn't rebinding a custom implementation to an interface not a good solution?
Now if you have the need to use a custom broker you can try this:
The built-in ForgotPasswordController controller uses the SendsPasswordResetEmails trait which defines a broker method that returns the broker instance. You can override the broker method on your controller and return a custom broker that implements the \Illuminate\Contracts\Auth\PasswordBroker interface. The ResetPasswordController uses the ResetsPasswords trait which exposes a public method named the same which can also be overridden.
These are the only two parts of the framework which currently use the broker, so, in my opinion, it is pretty straightforward to replace by a custom implementation (I actually replaced them in an old project). I agree this is not the most elegant solution but it is something that can solve a custom requirement.
JackPriceBurns
Laravel gives you a huge amount of customisation with authentication in that you can create custom user providers and/or auth guards.
This is great, however password resets is where I feel this system falls short, the point of a custom user provider is that it enables you to retrieve & validate users through a different database backend, however the laravel password broker is a hard coded class and the only way to change this is to re-bind it in the service container (which is not a good solution) and this hard coded class only supports one type of database backend?
Essentially the ability to define your own password brokers that get used instead of the default laravel one is what this is about. I would be happy to contribute and create a PR myself.