Add a method to force a redirect to a non-Inertia URL about inertia-laravel

[reinink]

@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.

[reinink]

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');
    }
}

[bluekable]

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.

[fourstacks]

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?

[reinink]

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

[jartaud]

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]

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]

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

[danrichards]

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]

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]

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]

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

[Livijn]

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');
        }
    }
}

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]

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

[ahmadrio]

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

[aacassandra]

well done, thanks @reinink

[ahmadrio]

wow thanks @reinink

[chrisidakwo]

Amazing work, man! Amazing work! @reinink

[hugo-abdou]

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;
    }
});

[ahmadrio]

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