Support the ongoing development of Laravel.io →
Input Session
Last updated 1 year ago.
0

The people I've heard of having problems with cookies solved it by making sure their site domain is correct in the session config file. Have you tried this?

Last updated 1 year ago.
0

Thanks for the response but unfortunately that didn't fix the issue.

The site does make use of subdomain routing and I have to setup a few subdomain virtual hosts to get it to work locally. I don't think this is the problem though because the cookies don't persist on the sections of the site that don't use subdomain routing.

Last updated 1 year ago.
0

Actually, now I see that the session file is persisting across the pages on the primary domain. It only generates a new session on every page load when I am in a subdomain route. I don't know what I changed to at least fix the front-end part of the site.

Last updated 1 year ago.
0

I have this exact same problem after upgrading! I've tried changing my domain but it makes no difference.

Last updated 1 year ago.
0

Hey Guys,

Was having this same issue with a legacy package of code that was still making direct $_SESSION calls and depending on laravel to session_start().

In 4.1 the following occurred:

"Improved Session Engine

With this release, we're also introducing an entirely new session engine. Similar to the routing improvements, the new session layer is leaner and faster. We are no longer using Symfony's (and therefore PHP's) session handling facilites, and are using a custom solution that is simpler and easier to maintain."

So if you are using $_SESSION make sure to session_start(); manually.

Hope this helps someone.

Last updated 1 year ago.
0

I checked all my code and nothing uses $_SESSION. I don't think this is the issue.

Last updated 1 year ago.
0

My problem was that I had echo statements in my function. It was keeping the session from being properly created/stored.

Details: http://brainwashinc.com/2014/02/17/laravel-sessions-not-workin...

Last updated 1 year ago.
0

I am having the same issue after upgrading.. Nothing is echoed before redirect .. On a clean 4.1 install with the same configuration everything works fine.. I am trying for somedays now to find a solution.., i ll start having bad dreams about this:P

Last updated 1 year ago.
0

pns2050 said:

I am having the same issue after upgrading.. Nothing is echoed before redirect .. On a clean 4.1 install with the same configuration everything works fine.. I am trying for somedays now to find a solution.., i ll start having bad dreams about this:P

I know I am! please post if you find anything.

Last updated 1 year ago.
0

Same issue.. googled for 3 days.. didn't find any proper solution. now i think.. i will become made. session is not perssisting on my shared host server works fine on local with laravel 4.1. please some one mail to taylor..!!

Last updated 1 year ago.
0

Hello, I did some more tests and, in my case, the problem is in the auth filter, I will explain:

1 - I created a new project with Laravel 4.1 *. 2 - I installed Confide for Authentication 3 - I tested, tested and tested and everything worked as expected, I logged exits, I logged and everything normal. 3 - I was in the route.php file and includes the route Route :: when ('admin', 'auth'), so that only logged entered. 4 - From there, it stops working, you log in, it comes standard, when it redirects to / admin, the user is not logged in. pro and back again. Is there any bug in Auth class that is doing it. and useless to remove the route Route :: when ('admin', 'auth'); pq will not work anymore, only a new installation.

If someone finds the BUG, post here for everyone.

Last updated 1 year ago.
0

It's not fix after so long ??.... I'm facing this issue too :(

Last updated 1 year ago.
0

Same here. I didnt upgraded just moved my local laravel to another server.

Last updated 1 year ago.
0

I'm sorry to resurrect this once again but I am still having this problem many months later. I once again created a Laravel 4.1 upgrade branch off of Master and went through the upgrade process. I found that cookies are written and persist when I am navigating pages at the root domain (ex: mysite.dev) but as soon as a subdomain is involved (ex: company.mysite.dev), the cookies aren't written and new session files are generated on every page load. It occurred to me that maybe the layout or route filter we are using could be outputting something before the headers are sent so I tested one route by returning a small JSON response but I still have the problem. Cookies do not persist thus the session does not persist either.

We NEVER had this problem with Laravel 4.0., just Laravel 4.1. ever since its release. Like last time, I followed the upgrade guide perfectly. Everything about my local environment is the same as it was before. The only difference now are the things that appear in that upgrade guide. What could be happening here?

Also, it has nothing to do with the session 'lifetime' value. It is not and has never been set to 0.

Response: {"hello":"ben"}

Response Headers: HTTP/1.1 200 OK Date: Tue, 15 Apr 2014 17:07:53 GMT Server: Apache X-Powered-By: PHP/5.5.3 Cache-Control: no-cache X-Frame-Options: SAMEORIGIN Set-Cookie: app_session=eyJpdiI6IlBrVnNESzNxUkJ0TH... (abbreviated); expires=Thu, 17-Apr-2014 17:07:53 GMT; Max-Age=172800; path=/; httponly Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: application/json

Last updated 1 year ago.
0

The only solution that i found was to revert back to laravel 4.0

Last updated 1 year ago.
0

We had this issue and were able to fix it by making sure the following two configurations in session.php were in sync:

expire_on_close, lifetime

Our issue was caused by having lifetime set to 0 and expire_on_close set to false, which caused a situation where Laravel didn't know how to handle the cookie. By simply setting lifetime to a positive number, or setting expire_on_close to true the issue disappeared.

Hope this helps!

Last updated 1 year ago.
0

pin post

Last updated 1 year ago.
0

jcrowe206 said:

We had this issue and were able to fix it by making sure the following two configurations in session.php were in sync:

expire_on_close, lifetime

Our issue was caused by having lifetime set to 0 and expire_on_close set to false, which caused a situation where Laravel didn't know how to handle the cookie. By simply setting lifetime to a positive number, or setting expire_on_close to true the issue disappeared.

Hope this helps!

Have same issue and now everything is fine. Thanks a lot!

Last updated 1 year ago.
0

I have the same issue and the answers proposed here do not work for me.

Am running my application on subdomain.

If anyone finds another elegant answer please post.

Last updated 1 year ago.
0

Has anyone had any success with this? I am at the absolute end of my ropes with this problem. Sessions are being generated on each request, I tried using file and database sessions, same result. Ive tried every suggestion I could and nothing helps. On login attempts, I see 3 additional sessions being created most of the time and neither one persist, I immediately get 401's. I used the built in Auth and tried Sentry and both give the same results.

I really dont understand why something as simple as session & cookie persistence has to be this problematic. I really feel like my only other course of action right now is to just dump laravel all together.

Last updated 1 year ago.
0

Well everyone, after many months of pulling my hair out and longing for the days of using Laravel 4.1 (now 4.2) on this project, I can happily report that I have discovered the cause to this problem in our case.

Whatever you do, do not overwrite your application's encryption key during the request and leave it that way!

<?php

// Just a sample of what to look for. Not what we actually had.
Crypt::setKey($somethingElse);

Laravel's routing engine was rewritten for Laravel 4.1 so I am guessing the timing of when Laravel checks for an existing session and/or writes the session cookie changed. Seeing as how the cookie is encrypted, having an inconsistent encryption key would be a problem.

I found the guilty code in our routes.php file. It was calling a function that modified the encryption key for the remainder of the request.

Last updated 1 year ago.
0

Hey dudes

I've the same problem and after some test I've found the raise of problem. In my case the Laravel 4.0 Session 'lifetime' was 0 and don't cause problems, but in 4.1 / 4.2 version lifetime 0 cause recreate session, the solution is put one number, take look 120 (2 hours).

GoodLook

Last updated 1 year ago.
0

I managed to fix this issue after two weeks of headache, Actually what I have done is to clear the cookies in my browser and it worked like a charm.

0

I had this same issue, and drove me mad, the only solution that worked for me was cleaning the cookies in the browser. Thanks @kamaroly!

kamaroly liked this reply

1

The issue was solved by fixing the user permissions in the "storage" folder on the server.

0

having this issue now, and driving me like hell, none of the solutions iv'e tried worked. i tried also switching to database and cookie driver but still no luck.

0

Sign in to participate in this thread!

Eventy

Your banner here too?

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.