Please allow generic requests to be passed into the login pipeline

[Mark Lambley]

fortify/src/Http/Controllers/AuthenticatedSessionController.php

Lines 64 to 70 in ee4d41b

     /** 
      * Get the authentication pipeline instance. 
      * 
      * @param  \Laravel\Fortify\Http\Requests\LoginRequest  $request 
      * @return \Illuminate\Pipeline\Pipeline 
      */ 
     protected function loginPipeline(LoginRequest $request) 

Please change the method signature to be \Illuminate\Http\Request $request

My use case is that I'm attaching access tokens directly to my sales orders, and then emailing customers a link which will authenticate them and give them just enough permissions to view and leave comments on that sales order.

I'm achieving this by adding code into my Fortify::authenticateUsing callback, checking the token and returning a \Illuminate\Auth\GenericUser

I've got my own class which extends AuthenticatedSessionController, however I cannot call loginPipeline because it expects a LoginRequest. But as far as I can see, none of the classes in the pipeline specifically require this class - they only expect to see a \Illuminate\Http\Request

I think that this can be changed, however I acknowledge that it is a breaking change to a protected function.

[Dries Vints]

If you want to change anything feel free to attempt a PR, thanks.

[Dries Vints]

This probably needs to go to master for the next release as it'll be a breaking change. I don't think it makes a high chance of being excepted though, sorry.

[Michael]

I just would like to add that I try to create an email login. User enters the email address, I inject my own AttemptToAuthenticate class in the pipeline, making use of loginThrough.

The problem is that I have to send a random string for the password when posting the login, as the validation in LoginRequest doesn't let me get through to the pipeline.

Another problem is that I can't add more validation rules to LoginRequest as I have a multi auth setup and a dedicated table of users only for that login. Hence a user from the other user group can enter his email address, but fails with the login after using the email login link. Would be nice to prevent that all together.

edit
Found another way, in the FortifyServiceProvider did

public function register()
    {
        if (Str::contains(request()->getHost(), 'subdomainname')) {
            $this->app->bind(LoginRequest::class, function ($app) {
                return $app->make(EmailLoginRequest::class);
            });
        }
    }

[Mark Lambley]

@michaelklopf That's all kinds of awesome, and it's a clean solution. A subclass which just kills off all the validation rules and allows you to specify your own.

[Alex Scotton]

@michaelklopf I just had to take the time to reply to thank you. This is amazing and I'd never realised the power of re-binding in the IoC until just now with your example.

Please take the rest of the day off, tell your manager to say I said it was required 😆