$inertia.post() results in a 302 redirect.

[vannut]

I've got a small inertia app which gets loaded into another domain through an Iframe.

If i want to update something server side I make a request in the vue-component via:

this.$inertia.post(
  `/add-to-cart?ulid=${this.ulid}`,
  { test: 1234 }   
);

Serverside, in my controller I perform some logic en redirect the request to a second page:

return \Redirect::route('cart', [
            'ulid' => $request->get('ulid')
])
->withMessage([
    'label' => 'bijgewerkt',
    'type' => 'cart-bijgewerkt'
]);

If I visit the app on its own domain (so not iframed) this redirect works like expected. I end up on the cart route and there is a flash message.

But when the app is being iFramed, it does not work.
The logic (adding an item to the cart) is not being done, I dont see an item in the Database.
And If I look into the network tab I see the an XHR request being performed, with the correct POST data. But it has a response code of 302

Even when I just replace the whole controller method with a dd('hello') I would expect it to show up... but a 302 is again performed.

I'm a little bit lost on why this redirect is happening or even where it comes from!

[ajnsn]

This is probably a Token Mismatch Redirect because of the "Lax" SameSite policy. The XSRF-TOKEN cookie cannot be accessed when posting to your server via an Iframe.

Jonathan has sum up some more information here: https://inertiajs.com/csrf-protection. You can try to share the token as a prop and then include it in the post data, as mentioned in the beginning of the article.

There may be also other solutions availabe. But they require a more deep understanding what SameSite cookies are and how you need to configure them to keep your app secure.

[vannut]

The token will be generated for each request, that's the desired behaviour.

If it's the same session it should be the same right? Otherwise the server does not know the correct token to check it against. If I visit the iframed page outside the iframe the token remains the same over subsequent refreshes.

Just to confirm: you tried it inside an iframe, with samesite on lax?
I added the addHttpCookie to my middleware: no joy :(

[ajnsn]

Haven't tested in an iframe but your issue might now be the missing session-cookie, not the CSRF protection itself. To prove this, you could set session.secure to true and session.same_site to none. Then add protected $addHttpCookie = false; to the VerifyCsrfToken middleware. You should then only receive the session-cookie inside the iframe but the CSRF protection will be handled by sending over using the shared prop. Might be not a direct solution but session handling is another topic.

[vannut]

All right it seems that the session also must be stored with a cookie. Which because of the samesite policy gets rejected. And as the csrf token is bound to the session, it gets resetted on every request.

Though setting samesite=none would mitigate this and let the cookie to be set; safari on macOS 10.15 / catalina won't properply process this setting.

So in the end, I just don't use session management.

[ajnsn]

Oh dear, yes. Other options would be to use stateless tokens, like JWT or even transfering/exchanging the session ID within the headers and put it into localStorage. But this removes a lot of the simplicity that Inertia provides out of the box, so in the end iframes keep beeing complicated, maybe you can avoid them somehow.

[vannut]

The use case is a simple embed of (part of) my application a clients website. So I'm actually bound to use an iframe :) Thanks for your feedback!