inertiajs / inertia-laravel

The Laravel adapter for Inertia.js.
https://inertiajs.com
MIT License
2.1k stars 235 forks source link

Add a method to force a redirect to a non-Inertia URL #57

Closed sebastiandedeyne closed 4 years ago

sebastiandedeyne commented 5 years ago

Sometimes we want to redirect the user to a non-Inertia environment after a visit.

Inertia already supports something similar under the hood, for asset versioning.

https://github.com/inertiajs/inertia/blob/da004ee147cf53a7f02804f50dc0a324ecb9fdec/src/inertia.js#L83-L85

We added this little helper function in our app, but it feels hacky:

function redirectWithoutInertia(string $url)
{
    return response('', SymfonyResponse::HTTP_CONFLICT)->header('x-inertia-location', $url);
}

Would it make sense to add an Inertia::forceRedirect($url) method to inertia-laravel?

reinink commented 5 years ago

Yep, I like it. I've had a use-case for this once when redirecting to a 3rd party auth provider.

Not sure on two things:

  1. If using the conflict HTTP code is right for this use case. I almost wonder if we should have some type of Inertia "hard visit" response that's proper JSON.
  2. If forceRedirect is the right language. Right now it's called a "hard visit". Maybe it should be Inertia::hardVisit($url)? Admittedly that isn't as obvious as the word redirect.
raftalks commented 5 years ago

I have come across the use-case where logout gets redirected to a normal blade rendered page in laravel. The option 2 will be very handy.

m1guelpf commented 5 years ago

I've also had to use this, both with logout links & Socialite redirects. Would be really handy to have in core

jartaud commented 5 years ago

Thanks @sebastiandedeyne I was going nuts with the logout.

use Symfony\Component\HttpFoundation\Response as SymfonyResponse;

if (!function_exists('redirectWithoutInertia')) {
    function redirectWithoutInertia(string $url)
    {
        return response('', SymfonyResponse::HTTP_CONFLICT)->header('x-inertia-location', $url);
    }
}
crynobone commented 5 years ago

I would love to see this feature as well. Building an inertia checkout code and need to have an ability to redirect the user to external payment gateway.

choznerol commented 4 years ago

We added this little helper function in our app, but it feels hacky: ...

A rails version of the above workaround, for rails users come here via google search

# application_controller.rb

# Use `409 Conflict` to force client <InertiaApp> to go to +url+ with a full-page refresh
def redirect_without_inertia(url:)
  headers['X-Inertia-Location'] = url
  head :conflict
end
reinink commented 4 years ago

Here is another interesting use case for this feature.

Consider if you have a page in your app that isn't an Inertia page, but you somehow end up redirecting to that page via an Inertia request. You can use the asset conflict handling to force a full page load to these pages.

Something like this:

class LoginController extends Controller
{
    public function showLoginForm()
    {
        if (Request::inertia()) {
            return response('', 409)
                ->header('X-Inertia-Location', url()->current());
        }

        return view('auth.login');
    }
}
fourstacks commented 4 years ago

I think I might have another (similar) use case for this. My app has to authenticate at Shopify which involves a redirect offsite to do an oauth handshake. I therefore have to have my login form be a plain old POST form with an action and a hidden crsf token field.

This all works fine but the problem occurs when a session times out. I'm redirected to my login screen as expected on session expiry but a subsequent attempt to login results in a 419 token mismatch. This makes sense as there needs to be a full page refresh to get a new session token.

I've tried the solution in the snippet above and it works though it would be great to have a hardVisit solution that doesn't trigger a browser console error and if possible otherwise allows us to use the same Inertia API e.g.

public function showLoginForm()
{
        if (Request::inertia()) {
            return Inertia::hardVisit('Pages/Login')
        }

        return Inertia::render('Pages/Login')
}

Edit: on reflection I'm not really sure the above snippet makes much sense (or at least it might be a request for slightly different problem). I guess what I'm wondering is whether there could be a way of forcing an inertia view to hard reload under certain circumstances?

Livijn commented 4 years ago

I had an issue where I had to throw an exception in the Authenticate middleware since it doesn't allow for setting headers.

class Authenticate extends Middleware
{
    protected function redirectTo($request)
    {
        if (! $request->expectsJson() && Request::inertia()) {
            abort(409, '', ['X-Inertia-Location' => url()->route('login')]);
        } else if (! $request->expectsJson()) {
            return route('login');
        }
    }
}
ghost commented 4 years ago

Not sure [...] If forceRedirect is the right language. Right now it's called a "hard visit". Maybe it should be Inertia::hardVisit($url)? Admittedly that isn't as obvious as the word redirect.

How about hardRedirect()?

I had an issue where I had to throw an exception in the Authenticate middleware since it doesn't allow for setting headers.

@Livijn You could just override the unauthenticated() method from the parent class.

Edit: I'm wrong - the value from that method isn't returned as I first thought - but I think the Illuminate\Foundation\Exceptions\Handler::unauthenticated() method could be overridden in App\Exception\Handler.

crynobone commented 4 years ago

image

I recently update the deps from v0.2.6 to v0.2.7 and using SymfonyResponse::HTTP_CONFLICT no longer working as expected.

ahmadrio commented 4 years ago

Here is another interesting use case for this feature.

Consider if you have a page in your app that isn't an Inertia page, but you somehow end up redirecting to that page via an Inertia request. You can use the asset conflict handling to force a full page load to these pages.

Something like this:

class LoginController extends Controller
{
    public function showLoginForm()
    {
      if (Request::inertia()) {
          return response('', 409)
              ->header('X-Inertia-Location', url()->current());
      }

        return view('auth.login');
    }
}

thanks it works

reinink commented 4 years ago

@opanegro You no longer need to do this manually. The Laravel adapter now has a method for this, called Inertia::location. For example:

class LoginController extends Controller
{
    public function showLoginForm()
    {
        if (Request::inertia()) {
            return Inertia::location(url()->current());
        }

        return view('auth.login');
    }
}

More on that here.

aacassandra commented 3 years ago

well done, thanks @reinink

ahmadrio commented 3 years ago

wow thanks @reinink

danrichards commented 3 years ago
Inertia::location(url()->current());

I would suggest a mention under Manual Visits or Redirects in the docs. I wish I found this faster.

Thank you

reinink commented 3 years ago

@danrichards Hey there! So, this feature is already on the redirects page: https://inertiajs.com/redirects#external-redirects

chrisidakwo commented 3 years ago

Amazing work, man! Amazing work! @reinink

hugo-abdou commented 2 years ago

this is my solution for that in the front i check the response is not a valid inertia response and is a 200 status then I take the URL from the response and I make a redirection with window.location

Inertia.on("invalid", (event) => {
    if (event.detail.response.status == 200) {
        event.preventDefault();
        window.location.href = event.detail.response.request.responseURL;
    }
});
bluekable commented 1 year ago

This is brilliant!

One possible addition to the Laravel example in the Inertia documentation is that this can be implemented as middleware and then quite easily applied to multiple routes.

It makes it easy to then set apart routes that you know will never return an inertia response from those that will. It also might help with apps where devs want to implement Inertia into Laravel progressively.

Middleware like this:

class NonInertiaRoutes
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure(\Illuminate\Http\Request): (\Illuminate\Http\Response|\Illuminate\Http\RedirectResponse)  $next
     * @return \Illuminate\Http\Response|\Illuminate\Http\RedirectResponse
     */
    public function handle(Request $request, Closure $next)
    {
        if ($request->inertia()) {
            return Inertia::location($request->fullUrl());
        }

        return $next($request);
    }
}

Allows you to wrap routes like this:

// Non Inertia route for redirects to GrapesJS pages
Route::middleware(['non-inertia'])->group(function () {
    Route::get('/', [PageController::class, 'show']);
});

I had an issue using Laravel Breeze set up for Vue.js alongside laravel-grapesjs where if you visited a page to be edited by grapesjs before logging in (for example after session expiry) then you were redirected to login page and then again redirected to the edit route. But the edit route was not going to return an Inertia response so I would get the modal.

Alternatively if I logged out and wanted to be redirected to a grapesjs created page I would have the same issue.

In both cases I did not have control of the link that sent users to the URL as they were redirects - so this came in handy when trying to 'pop-out' of inertia for those specific routes.

ahmadrio commented 1 year ago

This is brilliant!

One possible addition to the Laravel example in the Inertia documentation is that this can be implemented as middleware and then quite easily applied to multiple routes.

It makes it easy to then set apart routes that you know will never return an inertia response from those that will. It also might help with apps where devs want to implement Inertia into Laravel progressively.

Middleware like this:

class NonInertiaRoutes
{
    /**
     * Handle an incoming request.
     *
     * @param  \Illuminate\Http\Request  $request
     * @param  \Closure(\Illuminate\Http\Request): (\Illuminate\Http\Response|\Illuminate\Http\RedirectResponse)  $next
     * @return \Illuminate\Http\Response|\Illuminate\Http\RedirectResponse
     */
    public function handle(Request $request, Closure $next)
    {
        if ($request->inertia()) {
            return Inertia::location($request->fullUrl());
        }

        return $next($request);
    }
}

Allows you to wrap routes like this:

// Non Inertia route for redirects to GrapesJS pages
Route::middleware(['non-inertia'])->group(function () {
    Route::get('/', [PageController::class, 'show']);
});

I had an issue using Laravel Breeze set up for Vue.js alongside laravel-grapesjs where if you visited a page to be edited by grapesjs before logging in (for example after session expiry) then you were redirected to login page and then again redirected to the edit route. But the edit route was not going to return an Inertia response so I would get the modal.

Alternatively if I logged out and wanted to be redirected to a grapesjs created page I would have the same issue.

In both cases I did not have control of the link that sent users to the URL as they were redirects - so this came in handy when trying to 'pop-out' of inertia for those specific routes.

thanks @bluekable

kh09211 commented 1 month ago

I was able to implement Inertia::location() with Fortify like this

use Laravel\Fortify\Contracts\LoginResponse;
use Inertia\Inertia;

class FortifyServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        $this->app->instance(LoginResponse::class, new class implements LoginResponse {
            public function toResponse($request)
            {
                return Inertia::location(redirect()->intended()->getTargetURL());
            }
        });
    }

    ...