I recently created a new Laravel project and was following along the guide on Authentication. When I visit either my login or register route, I get the following error:
ErrorException in Request.php line 775:
Session store not set on request. (View: C:\Users\Matthew\Documents\testesources\views\authegister.blade.php)
I haven't edited any core Laravel files, I've only created the views and added the routes to my routes.php file
// Authentication routes
Route::get('auth/login', ['uses' => 'Auth\AuthController@getLogin', 'as' => 'login']);
Route::post('auth/login', ['uses' => 'Auth\AuthController@postLogin', 'as' => 'login']);
Route::get('auth/logout', ['uses' => 'Auth\AuthController@getLogout', 'as' => 'logout']);
// Registration routes
Route::get('auth/register', ['uses' => 'Auth\AuthController@getRegister', 'as' => 'register']);
Route::post('auth/register', ['uses' => 'Auth\AuthController@postRegister', 'as' => 'login']);
I don't have much experience with Laravel, so please excuse my ignorance. I'm aware that there is another question asking this same thing, but neither of the answers seem to work for me. Thanks for reading!
Edit:
Here's my register.blade.php as requested.
@extends('partials.main')
@section('title', 'Test | Register')
@section('content')
<form method="POST" action="/auth/register">
{!! csrf_field() !!}
<div class="ui input">
<input type="text" name="name" value="{{ old('name') }}" placeholder="Username">
</div>
<div class="ui input">
<input type="email" name="email" value="{{ old('email') }}" placeholder="Email">
</div>
<div class="ui input">
<input type="password" name="password" placeholder="Password">
</div>
<div class="ui input">
<input type="password" name="password_confirmation"placeholder="Confirm Password">
</div>
<div>
<button class="ui primary button" type="submit">Register</button>
</div>
</form>
@endsection
You'll need to use the web middleware if you need session state, CSRF protection, and more.
Route::group(['middleware' => ['web']], function () {
// your routes here
});
If Cas Bloem's answer does not apply (i.e. you've definitely got the web
middleware on the applicable route), you might want to check the order of middlewares in your HTTP Kernel.
The default order in Kernel.php
is this:
$middlewareGroups = [
'web' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
],
];
Note that VerifyCsrfToken
comes after StartSession
. If you've got these in a different order, the dependency between them can also lead to the Session store not set on request.
exception.
If adding your routes
inside the web middleware
doesn't work for any reason then try adding this to $middleware
into Kernel.php
protected $middleware = [
//...
\Illuminate\Session\Middleware\StartSession::class,
\Illuminate\View\Middleware\ShareErrorsFromSession::class,
];
In my case (using Laravel 5.3) adding only the following 2 middleware allowed me to access session data in my API routes:
\App\Http\Middleware\EncryptCookies::class
\Illuminate\Session\Middleware\StartSession::class
Whole declaration ($middlewareGroups
in Kernel.php):
'api' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Session\Middleware\StartSession::class,
'throttle:60,1',
'bindings',
],
Laravel [5.4]
My solution was to use global session helper: session()
Its functionality is a little bit harder than $request->session().
writing:
session(['key'=>'value']);
pushing:
session()->push('key', $notification);
retrieving:
session('key');
in my case it was just to put return ; at the end of function where i have set session
A problem can be that you try to access you session inside of your controller's __constructor()
function.
From Laravel 5.3+ this is not possible anymore because it is not intended to work anyway, as stated in the upgrade guide.
In previous versions of Laravel, you could access session variables or the authenticated user in your controller's constructor. This was never intended to be an explicit feature of the framework. In Laravel 5.3, you can't access the session or authenticated user in your controller's constructor because the middleware has not run yet.
For more background information also read Taylor his response.
Workaround
If you still want to use this, you can dynamically create a middleware and run it in the constructor, as described in the upgrade guide:
As an alternative, you may define a Closure based middleware directly in your controller's constructor. Before using this feature, make sure that your application is running Laravel 5.3.4 or above:
<?php namespace App\Http\Controllers; use App\User; use Illuminate\Support\Facades\Auth; use App\Http\Controllers\Controller; class ProjectController extends Controller { /** * All of the current user's projects. */ protected $projects; /** * Create a new controller instance. * * @return void */ public function __construct() { $this->middleware(function ($request, $next) { $this->projects = Auth::user()->projects; return $next($request); }); } }
If you are using CSRF enter 'before'=>'csrf'
In your case Route::get('auth/login', ['before'=>'csrf','uses' => 'Auth\AuthController@getLogin', 'as' => 'login']);
For more details view Laravel 5 Documentation Security Protecting Routes
Do you can use ->stateless()
before the ->redirect()
. Then you dont need the session anymore.
In my case I added the following 4 lines to $middlewareGroups (in app/Http/Kernel.php):
'api' => [
\App\Http\Middleware\EncryptCookies::class,
\Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
\Illuminate\Session\Middleware\StartSession::class,
\App\Http\Middleware\VerifyCsrfToken::class,
'throttle:60,1',
'bindings',
],
IMPORTANT: The 4 new lines must be added BEFORE 'throttle' and 'bindings'!
Otherwise a "CSRF token not match" error will rise. I've struggled in this for several hours just to find the order is important.
This allowed me to access session in my API. I also added VerifyCsrfToken as when cookies/sessions are involved, CSRF needs to be taken care of.