Post reloads the page

Install Laravel debugbar. It will let you check things like the session to see if anything is being set. Its only a 3 minute install.

@SNAPEY - Hello Snapey, Thank you for your quick response. I installed Laravel debugbar, and I only ever see GET, never post after I submit the form, however if I look in the inspector in Chrome I see that a post request gets sent with the correct data (token, email and password):

General: Request URL: http://mysite.test/login Request Method: POST Status Code: 302 Found Remote Address: 192.168.10.10:80 Referrer Policy: no-referrer-when-downgrade

Response headers: Cache-Control: no-cache, private Connection: keep-alive Content-Type: text/html; charset=UTF-8 Date: Sat, 08 Dec 2018 21:06:41 GMT Location: http://mysite.test/login Server: nginx/1.15.5 Set-Cookie: laravel_session=eyJpdiI6IkZoTjdKeVh1UlwvNEpBUHRjRlwvVWVsUT09IiwidmFsdWUiOiJ2UmxwZ256bmRzR1BWQU8xMEczd1A5aCtlR0FaYzR6Y09UbUx0WWRuc1wvemprelpMUnRjcG1iNDNMQ0dyRVh1OSt2elA4Q2FoMjh1S29mSUR2cktuY0E9PSIsIm1hYyI6ImJlMWZiODI0NmQ4MmQ1MWJiY2I2OTdiZjFmODRhNDc0ZmFmOTg5YmU4MWVjNWRiZWVjZGQ1MTZmNzQ1NzYyYWYifQ%3D%3D; path=/; secure; httponly Transfer-Encoding: chunked X-XSS-Protection: 1; mode=block

Request headers: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cache-Control: max-age=0 Connection: keep-alive Content-Length: 102 Content-Type: application/x-www-form-urlencoded Host: mysite.test Origin: http://mysite.test Referer: http://mysite.test/login Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36

Form Data: _token: AIXGOYgtJxj89Sp7s7gWhrjf44GFyOc6NY9lg2jU email: [email protected] password: mypasswrd

...does anything look out of place? The production server is apache, but homestead uses ngnix of course. Let me know when you have a moment.

Thank you, Jonathan

Use the first party package for debugging ... Laravel Telescope

@ALIBAYAT - The laravel framework I'm using is not new enough to use Laravel Telescope. I'm on versuib 5.5.40 for this project.

@nathanoj oh then barryvdh/laravel-debugbar package might come in handy

@ALIBAYAT - It did not. I see post data in the chrome inspector, but I see no information about post data in the laravel/debugbar package. I see post data getting sent via the browser, but there is no post data getting to the request object in laravel

@ALIBAYAT - Here's something I discovered. If I remove the csrf_field class from app/Http/Kernel.php, I see the request object, but it is empty if I put this in routes/web.php

Route::get('login', function (Request $request) { return dd($request); });

So there are two questions. Why is the csrf blocking the request, and when it's not being blocked, why is there no data showing up in the request object in laravel? I've never seen anything like this.

This exact same code works perfectly on the production server running LAMP, but in the homestead environment it fails.

@nathanoj do you have " Auth::routes(); " in your routes/web.php file? if you do, that method defines routes for laravel authentication which one of them is a POST request to 'login' endpoint. that might be the conflict. try to send data by POST method to a different endpoint and see if it solves the problem.

@ALIBAYAT - So, I had commented out Auth::routes(); and I had flushed the routes cache. Never-the-less, If I change to something like:

Route::post('login', 'Auth\LoginController@otherendpoint');

and just dd($request) in the other endpoint function, I see what I want to see, so that's progress. Thank you.

Still, why is the csrf token blocking the request (I still have to comment that class out in Kernel.php) and, I had already commented out Auth::routes() so that, as a conflicting endpoint shouldn't have been the issue.

It's strange to me that this works on production. In fact it works in 3 different lamp environments, one dev environment on an ubuntu server and 2 others on elastic beanstalk which runs amazon's proprietary linux.

Jonathan

@ALIBAYAT - OK, I've tracked this down to the user is found, but the session never gets set, so every page load redirect to the login page. Not yet sure why this is happening.

When looking at Laravel Debugbar, on the right hand side there you might see #1 or #2 Debugbar keeps track of multiple requests. #1 will be the POST request and #2 will be the redirect.

Failure to create sessions can be caused by permissions on the storage folder. Have a look in the storage/framework/sessions folder to see if any sessions are being created.

@SNAPEY - I set that directory to read / write for everyone on my test environment. To me, the fact that the crsf token always fails is an indicator that the tokens never match and probably is an indicator of what might be happening.

I think there's something wrong with the auth key, or whatever is encrypting those tokens, including the sessions and crsf token, but what it is I can not track down. I could be wrong but when both sessions and the crsf token never match...

... sessions are getting saved. I checked that. It's something to do with a mismatch? ... maybe but I have regenerated the auth keys and reset the cache many times, so it's kind of driving me nuts at this point. I've never run into this issue and the live site has never either, but it scares the hell out of me because if it does ever happen on the live site I need to know why

@SNAPEY - I think if I can figure out why the crsf token never works on my test environment, then I will know why the sessions are also not working.

have you changed anything in the default config/sessions.php file, and in particular, the domain

@SNAPEY - Hi Snapey, No changes there. It has always looked like:

'domain' => env('SESSION_DOMAIN', null),

@SNAPEY - I just installed this site from scratch on the ubuntu server that I host my dev environment and it went off without a hitch. I wonder if it's a php version thing or something like that because there are differences there. This has been driving me nuts. Can you tell? :D

sorry, I should have asked. This will pull through domain from .env . Is it present there?

@SNAPEY - I only thing I have with a domain in it is this:

APP_URL=http://localhost

The .env file is pretty standard on my test vm. It's a copy of the .env.example file with a few other keys for outside services, like aws for example. I don't see anything with the key 'domain'. What should that look like?

This

'domain' => env('SESSION_DOMAIN', null),

sets the session.domain config element to whatever is SESSION_DOMAIN in .env or null if it does not say

We've had some people in the past set this to be something really specific which then causes session identity issues. But not in your case.. so, something else...

@SNAPEY - I managed to get this working without any issues using the 'Per Project Installation' listed here:

https://laravel.com/docs/5.5/homestead

Using those instructions, everything worked perfectly, although it redirected to https (which should only happen if it is a 'production' site). That was not a huge problem though as I was able to follow the instructions here:

https://medium.com/@adnanxteam/how-to-setup-https-with-laravel-homestead-ad7915470fa8

... which explains how to move and trust the certificate from the vagrant box

I will do per project installations from now on. I hope this helps anyone with the same issue.

Thanks Snapey and AliBayat for helping out.

@nathanoj

although it redirected to https (which should only happen if it is a 'production' site).

Not necessarily. Some domain extensions, like .app, are forced to use https by the browser. It's required and they will redirect to https. https://blog.nameshield.com/blog/2018/04/19/google-makes-https-hsts-encryption-mandatory-for-its-45-new-tlds/

A safe tld to use that doesn't require https is .test, which is reserved.

@CRONIX - Hmm, well that's bizarre. I am using the default url that is set with the 'per project installation' that I mentioned above at https://laravel.com/docs/5.5/homestead , which is 'homestead.test' ,

so I completely went with the default there. I only had to copy my .env file and run php artisan migrate

... and it still redirected to https! (?)

I'm glad it works, but I still don't understand what why that prior to the per project installation it didn't work. I was using a '.test' domain on that one as well, could not log in or get the token to match.

The only difference between this VM and the first one is that the one that worked is a 'per project installation' (and redirecting to https). Every other step I took was exactly the same.

Jonathan