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?
Related
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.
CodeIgniter 2 regenerates the session id on every http-call. This leads to problems with concurrent ajax calls. This makes it possible that client and server get out of sync and the session is lost. A Fix to this is not updating the session on ajax-calls (see Codeigniter session bugging out with ajax calls). But if you use CodeIgniter as an API for a single page application, where every call is ajax, this just leads to the session never being updated at all. The user just get logged out after the session timeout (default 5 minutes).
In CodeIgniter 3 they attempted to fix this by using a write lock (see https://github.com/bcit-ci/CodeIgniter/issues/3073) on session storage. Because this relies on a Database-Feature it is only possible to safely store session information in MySQL and PostgreSQL. Redis for example can not be used (see http://www.codeigniter.com/userguide3/installation/upgrade_300.html#step-6-update-your-session-library-usage).
Finally my question is: How does Laravel handle this Problem? Laravel can use Redis for session storage. So when does laravel regenerate the session id? And if Laravel doesnt regenerate it automatically on every http request, how can this be judged in context of security aspects?
Like pstephan1187 noted, "Laravel only regenerates the session ID when you sign in and sign out". CSRF Protection is used against cross-site request forgeries, and it consists of a field that is required by default (Laravel 5) in POST, PUT and DELETE requests.
Handling this in ajax-calls is outside the functionality offered by Laravel, but can be worked around pretty easily.
For more information about Laravel sessions, see the official documentation (Which, by the way, is a very nice and easy-to-understand read).
I have a Spring 3 MVC app and part of the app requires a redirect to a 3rd party payment site and that payment site redirects back to my app after it's done. The problem is that Spring seems to create a new session instead of using the old one and erases all the data previously stored in the session. This creates massive problems for my app and I'm wondering if there is a way to preserve the session after external redirect?
Also, cookie are enabled on my browser and I indeed verified that the jsessionid value in the cookie changes after the redirect, indicating a new session overwriting the old one.
Can you provide the following info:
After coming back from the 3rd party site, does your app use a different domain/sub domain from what it uses before redirecting to the 3rd party site?
Is there a possibility that your session timeout value is so low that the session expires by the time the user returns to your app?
Does your app use frames having onunload events that invalidate the session?