[Proposal] Rearrange how the redirect is implemented

[Krishan König]

Currently, the redirect logic is handled in the SocialController and always returns Redirect::route('home'). This causes some problems for apps who don't have a route named home. Ofc you can always override the SocialController class and write your own redirect response, but I think it would be a better user experience (for the developer) if the redirection logic is a bit more flexible by default.

If we take the login request then we could take the same approach that laravel/ui has taken for the redirect. That d mean that instead of calling authenticated() before authenticateModel(), we would call it afterwards.

// login logic
$social = $this->updateSocialInstance($request, $provider, $model, $providerUser);

$this->authenticateModel($model);

if ($response = $this->authenticated($request, $model, $social, $providerUser)) {
     return $response;
}

return redirect()->intended($this->redirectPath());

// redirectPath
    protected function redirectPath()
    {
        if (method_exists($this, 'redirectTo')) {
            return $this->redirectTo();
        }

        return property_exists($this, 'redirectTo') ? $this->redirectTo : route('home');
    }

That way we could utilize the alreadyt existent registered, authenticated, linked and unlinked methods to do custom redirects if required.

Would you be open to a PR which would make the necessary changes to the codebase @rennokki ?

[rennokki]

This has to be implemented. The idea behind not using this was that you can extend the controller and overwrite the method, but that would mean DRY gets broken, and the redirect method is the way to go for extending the controller.

[stale]

This issue has been automatically closed because it has not had any recent activity. 😨

[stale]

This issue has been automatically closed because it has not had any recent activity. 😨

[rennokki]

This was fixed. I was late a few months, haha. Read the new readme to get used to the new redirection stuff.