Asked  7 Months ago    Answers:  5   Viewed   60 times

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:UsersMatthewDocumentstestresourcesviewsauthregister.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' => 'AuthAuthController@getLogin', 'as' => 'login']);
Route::post('auth/login', ['uses' => 'AuthAuthController@postLogin', 'as' => 'login']);
Route::get('auth/logout', ['uses' => 'AuthAuthController@getLogout', 'as' => 'logout']);

// Registration routes
Route::get('auth/register', ['uses' => 'AuthAuthController@getRegister', 'as' => 'register']);
Route::post('auth/register', ['uses' => 'AuthAuthController@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!


Here's my register.blade.php as requested.


@section('title', 'Test | Register')

    <form method="POST" action="/auth/register">
        {!! csrf_field() !!}
        <div class="ui input">
          <input type="text" name="name" value="{{ old('name') }}" placeholder="Username">
        <div class="ui input">
          <input type="email" name="email" value="{{ old('email') }}" placeholder="Email">
        <div class="ui input">
          <input type="password" name="password" placeholder="Password">
        <div class="ui input">
          <input type="password" name="password_confirmation"placeholder="Confirm Password">
            <button class="ui primary button" type="submit">Register</button>



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
Wednesday, March 31, 2021
answered 7 Months ago

Actually i'm not even mad that's amazing because I found a solution to my problem... just around 5 min after I post my question... And I spend around 2 hours to find a solution...

All I did was:

php artisan clear-compiled
php artisan ide-helper:generate
php artisan optimize

and reload the blade.php.

I have no idea why, but it works now. It seems I forgot to run the above commands after I got Laravel Collective 5.2 in the project. This could be the reason that form command didn't work. .___.;;

I hope someone could use this information for their own project.

Wednesday, March 31, 2021
answered 7 Months ago

As far as I can see and understand you're telling your unit test that when you call $request->has() on your request object that it should return the $requestParams array, not true or false, or anything else.

Unless you specifically check what is send with a method call your mock doesn't actually care what is send, it just cares that it was called.

You might want to explore creating an empty request and filling it with data if that is possible in your use case as that'll let you run your unit test with more ease and less issues. This won't work in all cases.

You could include what assertions you're making in your unit test so we can see more clearly what you're running into, but as it is. It returns exactly what you're telling it to return. Even if that's not what you actually want it to return.

Mocks are used to separate your Unit-Test from the rest of your system. As such you usually tend to only check if a specific method is called to see if your code actually exits to the class you mocked and if it has the expected data you'd send along. In some extreme cases you can want to mock the system you're actually testing, but this usually indicates that your code is too dependent on other classes or it's doing too much.

Another reason to use mocks is to satisfy Type Casting constraints in your method calls. In these cases you'll usually create an empty mocked object and fill it with some dummy data your code will accept or break on to test the code.

In your case it seems you want to check if your code actually works correctly and for this I'd suggest either not mocking the request, or making specific tests where you tell it to return true, or false (test for both cases)

So something along the lines of:

    ->willReturn(true); // or false in your next test

Edit: As you mentioned in the comment Below you ran into the issue that you're using the has method multiple times in your code and ran into issues.

The Questions I've linked to in my response comment go into greater detail but to sum it up, you can use an inline function or the at() method to deal with multiple cases.

With at() you can supply specific iterations of the code to hit only that bit of the test. It has been mentioned that this makes your tests rather brittle as any has added before the previous ones would break the test.



The inline function (callback) solution would allow you to customize your test to allow multiple cases and to return data as required. Unfortunately I'm not too familiar with this concept as I haven't used it myself before. I suggest reading the PHPUnit docs for more information about this.

In the end I'd still suggest not mocking the request and instead making an empty request that you'll fill with the data you want to check. Laravel comes with some impressive methods that'll let you manually fill the request with a lot of data you'd usually test against.

For example you can add data (post/get data) by using

request->add(['fieldname' => 'value'])

As a last few pointers I'd like to mention that it seems you use var_dump. Laravel comes with two of it's own functions that are similar and quite useful in debugging. You can use dd(); or dump(); dd(); dumps and stops the execution of code, while dump(); just outputs whatever you decide. so you could do dd($request); or dump($request); and see what the variables/class objects/etc holds. It'll even put it in a rather spiffy layout with some Javascript and such to allow you to see what's in it and such. Might want to check it out if you didn't knew it existed.

Wednesday, March 31, 2021
answered 7 Months ago

You are Flashing session data and creating a view instead of redirecting, meaning the message will Flash for this request and for the next one, showing twice.

If you want to show the message on the current request without redirecting, I would suggest providing the errors to your View::make instead of trying to Flash the messages. If you MUST Flash the message on the current request, then you will need to Session::forget('key') or Session::flush() after your view.

Saturday, May 29, 2021
answered 5 Months ago

From the Socialite documentation

The stateless method may be used to disable session state verification. This is useful when adding social authentication to an API:

return Socialite::driver('google')->stateless()->user();

Saturday, May 29, 2021
answered 5 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :