I've developing an update to an existing Laravel System (currently running Laravel 6 and PHP7.4), that runs on both EC2 and Laravel Vapor Setups, and have run into some very strange issues that only present themselves on Vapor Setups. These issues relate to Cookie Generation Failing and POST Routes being ignored when handling Routes.
Issue #1: Cookies No Longer Being Set
The first issue presents itself immediately upon loading the system up for the first time, no cookies are being saved, even though our .env is configured to do so:
SESSION_DRIVER=cookie
Without Cookies being generated, forms can't be processed and users cannot be marked as authenticated.
The system itself has had no changes made to it in areas that would touch core logic around Cookies, but none are now being generated. If we revert the codebase to the previous release without these changes, the system runs perfectly on the Laravel Vapor Setup, but runs without issue using both version of the code on the EC2 Setup.
Potentially Related: Redirecting users seems to be being done with JavaScript on the problematic Vapor Setup, whilst EC2 and Local Development Environments are managing to do so using headers. This indicates there's an issue somewhere in the code that's being used, but the areas that manage that code, as mentioned a few times, haven't been touched during development.
Issue #2: POST Routes Being Ignored
This might be a run on from the first issue above.
POST Routes are being completely ignored from our web.php file. I've tried submitting forms, I've tried using Insomnia to make requests to them, and have even tried setting up a route that would catch requests to any route that was using the POST method, and in each case they were being completely ignored by the system.
Submitting our login forms leads to a strange error being output:
Call to a member function can() on null (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php) (View: /var/task/resources/views/core/main/parts/headermenu.blade.php)
This error is strange because it should only be displayed after a user is authenticated, but submitting any details to the system gets this output, even blank details. I'm not sure how the user ends up on an authenticated page, as the POST route that handled authentication is being ignored, so no authentication logic is ever being run. I can, at least, confirm that the system is able to connect to the database to run verification logic, but the route that does so is never accessed because of this issue.
Honestly, I'm coming up blank on solutions to both of these issues, but they're blocking progress with this feature. Any and all guidance on where to look, or how to resolve the above would be most greatly appreciated.
Related
I made my first laravel project using Breeze authentification (laravel 9.2).
Everything is ok in local, I can register and login users.
But unfortunately in production on my server, login form and register form don't work so well !
I made a second laravel project, with only authentification functionnality to check if the problem come from part of my app. But the problem repeats : nice in local, does'nt work in production... I don't understand why.
When I submit my new created user or login with an existing user, the form reloads without performing the action...
I have this 404 error in my network console :
POST https://www.prod-breeze.yannpollet.fr/register [HTTP/2 404 Not Found 411ms]
My route login or register exists of course, created automatically with breeze installation.
I read in some forum that Breeze doesn't support https, but i can't believe it.
Anyone has the same problem or know hot to resolve it ?
I have set up an application load balancer on AWS. I am able to access my site but when I try to log in, I was redirected to a page with the message "The page has expired due to inactivity. Please refresh and try again I try taking out the ALB and the site work normally but when put on ALB then I keep getting the inactivity page.
I am using Laravel 5.5, hosted on ubuntu 16.04
I set my session and cache on database hope it will solve the issues but I still got the same problem.
I tried to turn off VerifyCsrfToken middleware, I wasn't redirected to the inactivity page but it keeps redirecting me back to the login page.
I managed to find a solution to my problem. My APP_KEY was different for all 3 servers, therefore, causing the problem. After changing it to the same APP_KEY in the .env then everything is working fine.
Hope this will help anyone who encounters a similar problem.
Once my webpage is deployed in IIS it seems that i am unable to properly switch tenants until i log into the default/host first. I don't want to require my users to have to do this before being allowed to switch to the tenant. It seems like the view is not properly being updated but i'm not sure why. I am using the ASP boilerplate template as a base and have not changed any of the login code/functionality at all.
So i tracked down the issue. For some reason when it goes to set the document.cookie value that includes the path and expire along with the tenant ID for whatever reason the browser is not updating the document.cookie with the according values. The javascript itself is not failing.
The fix is to just set the tenant portion of the cookie by itself and it works. Maybe someone can explain this behavior, but i tested the string and it will update the cookie just fine if i have logged into a tenant or host first.
Just seems once the session times out or is marked as bad this issue comes up.
I am working on Laravel 4 application and using Sentry for authentication. I need to add Keep Me Logged In functionality into my application. I have googled around and found that passing second variable to Sentry::login($user, $remember) sets up a cookie. I have done that and can verify that it is working from the browser (Chrome). But somehow whenever I try Sentry::check() after a day it returns null for cookies. Even when the cookie is present in the browser. Can anyone point out what am I doing wrong? Same happens when I attach my custom cookie to the response.
This scenario happens on my production server. Whereas it works fine on my local server.
PS: Lifetime of the cookie is set to forever (5 Years)
After working around for sometime on the issue I was finally able to resolve the issue by creating and attaching custom cookie to the response after login. And then wrote a middleware to check for that cookie. If present then login user and continue.
Our Laravel 5.1 application has been using the "native" session driver setting (configured in the .env file). With it set this way, we were able to use the laravel url.intended behavior to redirect the user to the url they were attempting to access prior to being authenticated.
We had to change it to "cookie" because every time we use Amazon's Opsworks system to deploy a new build, users were logged out because their server-side session files were no longer available. Once we changed it to cookie, the users remain logged in even when we deploy a hotfix or new build.
However, with it set to cookie, the url.intended does not work at all. I tried hacking together some solution by adding a custom url intended node, but it just won't work. It seems like when the user attempts to access a url prior to being logged in, it sets the session info, but then the application redirects the user to the login page where it's getting nulled out.
I'm using Debugbar to look at the session vars and I'm going crazy. I'm already bald so I have no more hair to pull out.
Does anyone have any ideas?
We ended up setting up a Dynamo database at first and then transitioned to Redis on a common server. We have a load balancer and don't want sessions getting lost or corrupted by switching servers so all cache is now being stored in that common location.