X-Inertia blocked by network security?

[PollieDev]

Hello all,

One of my customers is experiencing the issue where the response shows the modal with "All Inertia requests must receive a valid Inertia response, however a plain JSON response was received."

I can confirm that the request normally is a valid Inertia request. The user is able to load in the login page. But when successfully authenticated they receive that modal. I notice that the JSON is what Inertia send to the front-end. It includes the component name (which would be the correct one after being authenticated) and it contains all data as expected.

I myself am unable to reproduce the issue. They are using Edge in incognito, again I was unable to reproduce it in Edge incognito.
I have extensively looked through logs and our monitoring. Everything is pointing to it being a valid Inertia request. However they still run into that issue.

I wanted to check in whether any of you experienced the same or had any ideas what it could be.

The customer is part of an enterprise company. So one assumption I have is that their enterprise network is blocking unknown headers, therefor blocking X-Inertia. Which is, to my knowledge, a requirement to be a valid Inertia request. If that's the case, then this flow would make sense, right? - Up to them to then whitelist this header.

I am currently in contact with said customer to check on the network situation. But didn't want to waste too much time so wanted to check in with all of you if anyone else had another idea or another potential cause in mind.

Thanks in advance,
Pollie

[francoism90]

@PollieDev How do you submit the login (VueJS?) and handle the controller authentication?

[francoism90]

That seems indeed how the starter kit does this: https://github.com/laravel/vue-starter-kit/blob/9e67e4241bed78bd587e3f4ded7dacfbb274611a/app/Http/Controllers/Auth/AuthenticatedSessionController.php#L31

Do you also use Fortify? I'm using this, but instead just use the auth handler directly from it (not a controller like the starter-kit).

I don't know for sure if you need to expose or handle that header somewhere. Are you accessing this over CORS or by proxy?

[PollieDev]

That seems indeed how the starter kit does this.

Yeah, it's indeed just the starter template I have used.

Do you also use Fortify?

I don't think the start kit uses Fortify. I have not installed Fortify myself, so no.

I don't know for sure if you need to expose or handle that header somewhere. Are you accessing this over CORS or by proxy?

I am using Cloudflare as a proxy, and running nginx as web server on the instance itself.
I am using the default configuration of Cloudflare and Laravel/PHP-defined configuration on nginx.
Pretty confident Cloudflare and nginx aren't the cause as I use identical configurations on many other sites without issues + all other customers are not experiencing the issue on this site. Very maybe Cloudflare has like a specific security in place? Would surprise me though.

[francoism90]

I meant if you use Fortify, I think in the starter-kit it only uses the 2FA features?

I don't know much about the Cloudflare proxy. If this is a subdomain, not on the same domain or being pushed through proxies, it could be you need to define that exposed_headers in config/cors.php or configure to trusts proxies (see Laravel docs for details).

[PollieDev]

I do not use Fortify, no. Also got an update from the customer they experienced the issue on non auth-routes. They were logged in, tried going to another page and experienced the issue. So don't think any auth related features could be a blocker.

The cloudflare config and laravel config are things I looked into as well, but I doubt that would be the cause because as mentioned nobody else has this issue, and the same configuration is used on other projects without issues.

That's why I'm personally pointing to something externally. But struggling to nail that down at the moment. Customer is also not all to tech-savvy so makes it quite hard.

Appreciate your input to cover all cases.

[francoism90]

This is the only thing I can think about: https://laravel.com/docs/12.x/requests#configuring-trusted-proxies

Hopefully you can find out why it's happening. I think something indeed removes the header or prevents it from passing it.