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.
Related
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.
I have a Laravel 4.2 web app running under a reverse proxy. I observe that Session Id (Session::getId()) changes randomly when user login to the system, but the PHPSESSID didn't change.
I wonder why somehow Laravel Session Id is affected by the proxy but PHPSESSID does not (because everything runs very well without the proxy set up). I digged into the framework but I didn't figure out the root cause yet. How can Illuminate\Session\Store manage to get the Session ID?
I'm just installed a fresh L5 app. I'm attempting to use database driven sessions however a new session appears to be created on each page load.
Has anyone come across this issue and managed to resolve?
"_token" value is new on each refresh.
I'm happy that the cookies have been configured correctly.
Not sure where to look next.
Any suggestions would be a huge help.
Thanks in advance
Have you ensured your session domain is set correctly? Your session domain should be the domain alone, for example domain.com, no URIs or protocols (http://), etc.
You may also want to check that SESSION_HTTPS is set to false, unless you're accessing your site over https.
If either are not set correctly sessions will not be correctly stored by the browser, so each request results in a new session.
The _token key will always be a new value for each request, this is part of the CSRF security feature.