Open JackPriceBurns opened 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.
In normal circumstances, I would rebind the password broker in the service container and call it a day, however I am trying to make a package. If I pulled in a package and it started rebinding stuff in the service container I wouldn't be too happy.
As for the broker
method inside the ResetsPasswords
I don't have direct control over the users controllers otherwise this would be the perfect solution.
This main idea is because it seems strange you can't change the password broker using configuration, the entire authentication flow is designed to be able to define drivers and use them by just changing config values, but the password broker is the only part of the flow that is hard coded (if you don't have access to the controllers)
Makes sense, I didn't thought about this feature in a package.
If you have a working implementation I think you could PR that targeting master with a good explanation.
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.