13

I've got a Laravel 5.2 project that I'm using as a mock API for a javascript client I'm building out. The mock API functionality will be replaced with a different Laravel project later. For now, I just need to be able to submit API calls and get expected responses.

In my mock API I'm storing the authentication status in the session.

The problem I'm running into is that the values I put into the session are not persisting between http calls.

session put is not persisting gif

This seemed similar to a different stackoverflow post I found, but the thing is I'm already using the web middleware for my API group.

I thought it may be a permissions on my storage folder (I'm using the default file session driver), vagrant is the owner and has write access:

storage directory permissions

Plus if it was a permissions issue I would think it would generate a runtime error.

Is there something else I'm missing?

EDIT

Here's the contents of Config::get('session'):

contents of config::get('session')

And yep, the StartSession class is included in the web middleware group:

StartSession class in web middleware group

Here's a shot of the browser session cookie vs the session file being created on the web server:

browser cookie vs session file

Here's the content of the request:

request contents

Cœur
  • 37,241
  • 25
  • 195
  • 267
Chris Schmitz
  • 20,160
  • 30
  • 81
  • 137
  • What does `Config::get('session')` dump out, are files being created in `storage`, and have you checked that the session middleware is included in the web group? – ceejayoz Jan 06 '16 at 19:34
  • I updated my question with the answers to both questions. – Chris Schmitz Jan 06 '16 at 19:40
  • Clear out the contents of `storage/framework/sessions` and login. Do you see a file created? – ceejayoz Jan 06 '16 at 19:41
  • Yep, session files get created. And something interesting; each time I refresh the browser a new session record is created. Shouldn't it create and reuse one? – Chris Schmitz Jan 06 '16 at 19:44
  • Correct. Does your browser's inspector show a cookie with a session ID being created? – ceejayoz Jan 06 '16 at 20:13
  • Hmm!! We're getting closer. There is a cookie for the site, but it looks like the PHPSESSID doesn't match the name of the session record created. I've updated my question with a screen shot. – Chris Schmitz Jan 06 '16 at 20:20
  • Please print the `$Request` variable and show the output or even better, why not use the default Auth method to login?, when you use Auth automatically creates a persistent session :) – martinezjc Jan 06 '16 at 20:29
  • @ChrisSchmitz Laravel uses a cookie named `laravel_session` by default. *Not* `PHPSESSID`. – ceejayoz Jan 06 '16 at 20:35
  • @martinezjc re: "why not use Auth" I didn't want to dive into auth for what just needs to be a mock API. All I need is for it to return simple values to the client. The only reason I'm not just hard coding everything is because `check` does need to be dynamic. I could use Auth, but it still doesn't explain why I can't persist to the session. – Chris Schmitz Jan 06 '16 at 20:59
  • @ChrisSchmitz Do `\Sesson::` (rather than `$request->session()->`) calls work any better? – ceejayoz Jan 06 '16 at 21:27
  • Unfortunately no, `\Session::` gives the same results. – Chris Schmitz Jan 06 '16 at 22:29
  • very interested into an answer on this, i face the exact same problem .. – Laurent Jan 13 '16 at 04:51
  • Same here. I even tried on different OS's but seems it has nothing to do with the OS – adelindev Jan 13 '16 at 17:26
  • Well I'm glad I'm not alone at least :P – Chris Schmitz Jan 13 '16 at 17:30
  • Facing same issue as well. – Tania Petsouka Jan 14 '16 at 07:23
  • 1
    Added issue on github, https://github.com/laravel/framework/issues/11874 – Tania Petsouka Jan 14 '16 at 07:32
  • Facing similar issue. In my case I can see the session variable but it drops after say 10-15 refreshes. Also my user logs out automatically after 3-4 pages. Is this solved in Laravel 5.3? – Bharat Geleda Feb 14 '16 at 15:43

5 Answers5

8

I had the same issue and was able to get it to work by replacing

Route::group(['middleware' => ['web']], function () {
   ...
});

with

Route::group(['middlewareGroups' => ['web']], function () {
   ...
});

No idea why this works though when all the documentation suggests that we use ['middleware' => ['web']]

howellmartinez
  • 1,195
  • 1
  • 13
  • 24
  • this works. It should be the accepted answer, it gives the desired behaviour for now... – nonsensei May 11 '16 at 09:09
  • Interesting finding. I'm going to dig into this a bit and see if I can find out why. @nonsensei, I'm not marking this as the correct answer because it's not complete. Just because you have the desired functionality doesn't mean it's the correct answer for people to reference. My front door creeks so I completely take it off the hinges -> creeking stops. Just because it fixed the issue doesn't mean it's the correct answer. Once howell/I/you/we/someone else figure's out the actual _why_ and _how_ of the fix I'll give the check. I think this is a good start, but it's not completely correct yet. – Chris Schmitz May 16 '16 at 16:22
  • 1
    @ChrisSchmitz that doesn't make sense to me. It's the right answer to your question for Laravel 5.2. The root of your problem (and also mine) is in the "web" middlewares not loading. The cause is either a wrong documentation or a bug in the code. Sooner or later it will be fixed but for Laravel 5.2 THIS is the answer. If you want to use 'middleware' instead of 'middlewareGroups' you have to edit Laravel code. But it won't be version 5.2 anymore. ANYWAY I would, AT LEAST, thank him with an upvote because he took the effort and saved us some time! – nonsensei May 16 '16 at 17:04
  • @nonsensei, it's because there is not an explanation of what adding `middlewareGroups` does and why that fixes it. It could very well be that adding the value does correctly fix the issue, but saying "No idea why this works..." isn't a complete answer. If the answer was "this works because..." and there was an explanation of why you should do this and an understanding of the repercussions I would give it the check. There's nothing to stop you from doing the suggested answer, but before I put the check on it indicating that _I_ think this is what other users should do I want to research it more – Chris Schmitz May 16 '16 at 17:09
  • I am getting Undefined variable: errors when using middlewareGroup as have suggested. – Mandy Aug 01 '16 at 11:56
  • @nonsensei, check out this answer I accepted: http://stackoverflow.com/questions/34641229/larvel-5-2-session-values-not-persisting-even-when-web-middleware-is-used/39692060#answer-39692060. This answer explains the why, which (in my opinion) is more important than just giving the how. This answer makes the code work, but the one I marked correctly helps people understanding why. No disrespect to howellmartinez, his answer is rightly voted up, but the answer marked as correct should fully explain how to resolve the problem and why. – Chris Schmitz Sep 25 '16 at 21:41
  • @ChrisSchmitz we clearly have different points of views. as for me the currently accepted answer is "better" from an abstract point of view, but not from a concrete one! An answer "now" that the code has been fixed and updated has no value for me. I can find it by myself with very little effort. I needed an answer when the problem existed and howellmartinez pointed me in the right direction; his answer was valuable for me. Also the entire question has less value now instead of before. Sorry for my bad english – nonsensei Oct 11 '16 at 08:32
1

I have the same Issue on 5.2

I found out that sessions work if i register the routes and the middleware within a group

Route::group(['middleware' => ['web']], function () {
    Route::get('aktuell', "SeitenController@getAktuell");
    # other routes ... 
});

But not if i assign the middleware in the Controllers constructor

function __construct()
{
    $this->middleware('web');
}

(which is my preffered way..)

works though by saving session explicitly via

$request->session()->put("test3",time()."-anna");
$request->session()->save();
Mazz
  • 1,859
  • 26
  • 38
Flex Elektro Deimling
  • 1,599
  • 1
  • 17
  • 16
1

One thing that did the trick for me was to make sure that domain in config/session.php is set to null.

1

This is because of a change that was made to the Laravel that all routes by default are part of the "web" middleware, so assigning it again in your routes.php file ends up assigning it twice.

The solution is either to remove the "web" middleware from your routes OR remove the automatic assignment from the RouteServiceProvider.

Before the Laravel update:

  // /app/Providers/RouteServiceProvider.php
$router->group(['namespace' => $this->namespace], function ($router) {
    require app_path('Http/routes.php');
});

After the Laravel update:

// /app/Providers/RouteServiceProvider.php
$router->group([
    'namespace' => $this->namespace, 'middleware' => 'web',
], function ($router) {
    require app_path('Http/routes.php');
});

Notice how the new update automatically applies the "web" middleware to all routes. Simply remove it here if you wish to continue using Laravel 5.2 as you have before (manually assigning "web" middleware in your routes.php).

0

I experienced the same problem but none of the other answers helped me. For me the Illuminate\Session\Middleware\StartSession class was always called as it had to be, so I knew the web middleware was called.

When googeling on the problem I came accross the following thread where Taylor Otwell mentioned you have to use the Session::save() after setting the session variable. Using this worked for me, but I still don't know the reason why this solved the problem.

Jetse
  • 1,706
  • 2
  • 16
  • 22