#419 Page Expired error on every network request.

57 messages · Page 1 of 1 (latest)

icy arrow
#

My Laravel project was running completely fine and then I had to re setup the project in my laptop so I deleted the project directory and cloned the project in a new directory. After that I get 419 page expired error on every network request. It is showing that error in the network tab when any Livewire network request is triggered and also on any form submission eg. login form.

The project is running completely fine on other devices as I have asked my colleague to test it on their devices but only showing error on my device. I have resetup the project in completely new directory as well.

I have a Mac Book, with Laravel Herd recently added. The project is on Laravel 10 and also has Livewire.

I hope this clears my problem, please ask me if you want more details that I have missed out.

next crown
#

The best I can say with the info provided is you are somehow missing a csrf token in the request

icy arrow
final wasp
#

Att you allowing cookies on http (non-https)?

fickle lagoon
#

ENV setup correctly? Like session driver.. Did you clear cache/config? (time on your macbook is correct?)

icy arrow
icy arrow
final wasp
#

Check the headers tab in the image above, there may be an orange warning icon next to the cookies

#

Hover that go get more info

#

And look in session.php regarding the secure setting

icy arrow
#

There is no warning sign in the headers tab of the webpage, it says one cookies in use.

And the secure setting is on default.

final wasp
#

You need it disabled to use http

icy arrow
#

Even doing that didn’t solve the issue.

sacred ice
icy arrow
#

This is the network request through wire:model when I change the value of select option.

sacred ice
#

Alright, so I think you should remove the meta tag. I'd assume Livewire takes the csrf token from the cookie (as an SPA would), but the meta tag might mess with that

#

Hmm, looking at Jetstream it also has the meta tag. Didn't expect that tbh, don't use Livewire myself, so it was just a guess

icy arrow
#

But, my admin login which is not supported by the Livewire/or in the same layout, shouldn’t be affected by this problem I suppose. But Even with the login there is same 419 error

sacred ice
#

Then it sounds like a session issue, where you're getting a fresh session each request, thus the token doesn't match

icy arrow
sacred ice
#

Yeah, that seems like the session doesn't persist. Is the session cookie being blocked?

icy arrow
#

It doesn't seem to be blocked from anywhere. Do tell me if there is any specific place I should look.

final wasp
#

I still think the chrome dev tools will tell you why a cookie is not “sticking”, with an orange exclamation point icon in the “response headers” section. Hover on that to get the reason. Did you try to run the site locally with https (valet secure if you’re using valet)?

icy arrow
#

If this is what you mean, I do not see any Exclamation Marks, the one of the top right is giving a warning of "Error with Permissions-Policy header: Origin trial controlled feature not enabled: 'browsing-topics'." which is new and had not seen this before. I am sorry if I am not understanding what you are trying to convey.

icy arrow
#

I see there is no data stored in here where in fact the XSRF token and session value should hav been stored. But I cannot find any way how it can be blocked to store it.

sacred ice
#

Your page has no cookies at all, by the looks of it, not even a session cookie. So perhaps it's just your browser that's preventing all cookies, which would make any site rather unusable

icy arrow
#

But, other sites are usable and the problem exists in other browsers as well. Do you think this might be a issue of config?

wicked knoll
#

I had this happen yesterday in production and as far as I could tell it was caused by high resource usage of the database (mysql) once resource usage went back to normal the error stopped. There weren't any connection errors reported though which is what made it so odd

icy arrow
#

Well in my condition, the session doesnt seem to be stored in cookies, it just sends new one everytime and since it doesnt match it sends back the 419 error. I am not sure what to do now. Been stuck in this for a while, cannot even explain the situation to the client.

loud snow
#

@icy arrow is there anything in the session storage? Have you commented/removed any core middleware?

icy arrow
#

No, I have not removed any middleware, the project runs fine on other devices so I believe there is not problem with that..

If you mean the storage/framework/session there are multiple sessions being created on each network request or page refresh.

loud snow
#

I mean 'Session Storage' in the network tab

loud snow
icy arrow
icy arrow
loud snow
#

AddQueuedCookiesToResponse middleware is responsible for setting those cookies. If you're saying it works on other devices then it must be something with your device that's causing the issue.

final wasp
#

Can you show an image of the network tab response headers section, are there really no cookies there?

final wasp
#

Is that request the page navigation? The hash in the url is suspicious, are you using some form of spa-routing?

icy arrow
#

No, the hash on the url is a mistake.

icy arrow
#

Hi, people while the issue still hadn't been fixed, I couldn't figure out what to do and went on continuing with the development by disabling the CSRF checks and authentications on the local machine. The project was working properly in the staging website so I didn't think of it much and went on with the development. Today I deployed it to the production server and the same issue has repeated in the production server as well.

Can you please find what I was missing through this http://bhojanunlimited.com/

It would be a big help since the client is waiting for the website and it is still throwing errors.

Thank you

final wasp
#

There are no cookies whatsoever. So either you have excluded the StartSession middleware, but probably not since it works locally. If that's not it, perhaps you have a proxy that removes cookies? Check the hosting provider if there is a "allow cookies" toggle

#

You should also configure "force https"

icy arrow
#

It also doesn't work locally, but works on a staging server. But I will check for the allow cookeis toggle in the production hosting server

final wasp
#

Why would you put anything into production, or even a staging server, if it doesn't work locally?

icy arrow
#

No no, it was all working properly, I tested it and after it was working properly in my local computer, I pushed to staging/testing server. I had changed my admin dashboard from filament to laraadmin, so the repository were a bit messed up I fixed the repository and thought I would clean up my local project and reclone it form git.

After cloning from git again the project stopped working in my local, but it was properly working in the staging server. So I though the issue was with my local computer. I disabled the VerifyCSRF middleware and did some fixes and changes.

After that I proceeded to setup the production server since this was a new project, and I didn't think the issue will repeat there ( since the project was also running in other devices and also the staging server). But the same issue is there in the production server too.

I hope you got what I meant sorry for the poor english.

final wasp
#

Your english is great!

#

I understand – but if it's not working locally, focus on fixing that before worrying about production

icy arrow
#

Ok, what would be my next step of action becasuse I have checked a whole lot of possible solutions and ideas.

icy arrow
#

Hey @final wasp I seemed to have solved the issue.

There was a line before the "<?php" in the web.php file. I removed that space and now it seems to be working.

I have no clue how this is possible, since that same project was cloned into other devices and it was working there. I removed the same in the production server too now and its working there too.

final wasp
#

Great find! That would indeed prevent headers from being set, but that should also show as warnings in php logs

icy arrow
#

There was no logs set for that error, I do not understand how a blank space would affect this can you please explain if you have idea about it

final wasp
#

See the “Remember that…” section here. Cookies are set in a header, and headers must come before any output

#

Very hard to miss and almost impossible to track down such errors.

#

And, any content (including whitespace) outside php tags counts as output. That’s also why it’s good practice to not end php files with a closing tag

icy arrow
#

I see, thats great. Thank you so much for the help and valuable insights! @final wasp