Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

justindantzer's avatar

Jetstream/Inertia CSRF oddity

I've been helping out with some local development, trying out Jetstream and Inertia. Local development has been fairly smooth, and everything has for the most part just worked. However, we've thrown the app up on a server, and we're getting the dreaded 419 page expired error.

From what I can tell, the XSRF-TOKEN cookie exists in the response when loading the login page. However, the X-XSRF-TOKEN header is not getting appended when submitting login on the server. (everything works as expected locally) I will note we are using Apache on the server, whereas Valet uses nginx out of the box.

(using the standard Jetstream/Inertia/vue3 login view at present)

const form = useForm({
    email: '',
    password: '',
    remember: false,
});

const submit = () => {
    form.transform(data => ({
        ...data,
        remember: form.remember ? 'on' : '',
    })).post(route('login'), {
        onFinish: () => form.reset('password'),
    });
};

I saw some others reference a subdomain issue, causing the domain/origin to not match, and was hoping someone might know more about that subject.

I use Laravel Valet locally, so my local domain is similar to project.test. On the server, I'm using one of our play around .io domains, and the domain looks like project.domain.io.

The session or cookie domain are not being customized, outside of setting the APP_URL environment value. Flipping between the file and database session driver does not appear to make a difference.

Any advice or ideas of where to look would be greatly appreciated.

0 likes
5 replies
LaryAI's avatar
Level 58

The issue you're experiencing might be related to the domain/origin mismatch you mentioned. When you're working with subdomains, you need to ensure that your cookies are accessible across all subdomains.

In your config/session.php file, you should set the domain configuration option to your base domain, prefixed with a period. This will make the session cookie available to all subdomains of your base domain.

Here's how you can do it:

'domain' => '.domain.io',

Also, ensure that your SESSION_DOMAIN in your .env file matches the domain specified in your config/session.php file.

SESSION_DOMAIN=.domain.io

Remember to clear your config cache after making these changes by running php artisan config:cache in your terminal.

If this doesn't solve your issue, it might be related to a misconfiguration on your server. Ensure that your server is correctly configured to handle cookies and sessions.

Also, check if there's any difference in the way your local and production environments handle HTTPS, as this can also cause issues with cookies. If your production server is using HTTPS, make sure your SESSION_SECURE_COOKIE is set to true in your .env file.

SESSION_SECURE_COOKIE=true

I hope this helps! Let me know if you have any other questions.

MohamedTammam's avatar

What if you change your session domain env variable?

SESSION_DOMAIN=.domain.com
justindantzer's avatar

Unfortunately changing the domain did not fix the issue.

I will note that on other "test" Laravel sites using a subdomain with the .io domain have always functioned as normal, however, they are not Jetstream or Inertia based.

I am wondering if this could be a server configuration issue, so that will require some more digging.

MohamedTammam's avatar

@justindantzer for my point of view, if the code works good on development, then it's about the configuration. But Laravel configuration not the server itself.

justindantzer's avatar

Well... I found the issue.

This was in fact a server configuration issue. In a recent change to security protocols, it was decided to force all Cookies to Secure/HttpOnly on the server, like: Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=Lax

The default functionality of CSRF with axios is broken without access to the cookie, which is prevented by HttpOnly.

As a quick fix, I altered the setting to ignore the XSRF-TOKEN cookie like: Header always edit Set-Cookie ^((?!XSRF-TOKEN).*)$ $1;HttpOnly;Secure;SameSite=Lax

Now to go talk to the sysadmins.

Thanks for your quick responses @mohamedtammam

Please or to participate in this conversation.