Laravel's Auth::attempt() returns true but Auth::check() returns false

Question

As the title says, Laravel's function Auth::attempt() returns true in the following code section (with unimportant parts deleted):

public function doLogin()
{
    $validator = [..]

    if ($validator->fails()) {
        [..]
    } else {
        $userdata = array(
            'username'  => Input::get('username'),
            'password'  => Input::get('password')
        );

        if (Auth::attempt($userdata, true)) {
            return Redirect::to('/');
        } else {        
            return Redirect::to('login');
        }
    }
}

But when we are redirected, we try to check if an user is really logged in with Auth::check(), and it returns false somehow.

We have tried every possible solution on Google and did not succeed with any of it. For example we added a remember_token but it did not change anything, though it proved us that the Auth::attempt() does something because the remember_token is set in the database.

As a last resort, we even tried to print something in the Auth::attempt() method of Laravel in ./vendor/laravel/framework/src/Illuminate/Auth/Guard.php but we did not see anything of that, not even with print_r. We tried to find other attempt-functions in the complete codebase but none is found.

It could be that something about changing User to an translated form of it makes it broken, but then the function Auth::attempt() should also be broken, probably.

It seems that something really magical happens but we have no idea what or how. Does anybody else have an idea?

In `app/config/auth.php` which driver do you have set? And in `app/config/session.php` which driver is set there? — user1669496, Jan 05 '15 at 14:12
You could have some permissions on the file which is making it misbehave. Try modifying the permissions of the `app/storage/sessions` directory. If that doesn't work, see if it will work by using a different session driver. — user1669496, Jan 05 '15 at 15:01
We are working locally so the permissions shouldn't be a problem afaik. Using a different session driver doesn't help, we tried cookie and see that it makes the correct cookie but still the same problem. — Renzeee, Jan 05 '15 at 15:24
Do sessions in general work? `Session::put('foo', 'bar')` and in another request `Session::get('foo')` — lukasgeiter, Jan 05 '15 at 15:57
Hmm. So the session isn't the problem. Maybe the `remember` option is messing something up here. Have you tried `Auth::attempt($userdata)`? — lukasgeiter, Jan 05 '15 at 16:03
@Maximilian Prepl: yes, there are. One file as one would expect when trying to login with one account. If you want to see the contents, please say. — Renzeee, Jan 05 '15 at 16:11
@lukasgeiter: we tried that beforehand and again just now, but also no success, with and without statically deleting the `remember_token` from the database for the corresponding account. — Renzeee, Jan 05 '15 at 16:13
did you have modified `cookie` or `domain` var in `session.php`? — Maximilian Prepl, Jan 05 '15 at 16:17
@MaximilianPrepl: they are `laravel_session` and `null` respectively, and AFAIK we didn't change them. — Renzeee, Jan 05 '15 at 16:22
is there some messages in laravel.log under `app/storage/logs`? — Maximilian Prepl, Jan 05 '15 at 16:27
I had a similar problem that had me scratching my head for a while a few months back. It turned out that i replaced the default `User` model. Does your `User` model include all of the traits and namespaces as the [default User model](https://github.com/laravel/laravel/blob/master/app/models/User.php) in the Laravel distribution? — c-griffin, Jan 05 '15 at 19:36
@Renzeee I had similar problem today. Have you define primary key in Model?. because i have not define primary key in `User` model and after defining primary key everything works fine for me. So try this. May be this would help you. — Gaurang Ghinaiya, Sep 15 '15 at 07:54
@c-griffin The problem was indeed that we changed the User model. — Renzeee, Feb 22 '16 at 11:01

score 7 · Answer 1 · answered Sep 21 '15 at 11:34

7

By default, Laravel assumes that each table has a primary key called id.

Possible solution is to do this in your model:

protected $primaryKey = 'id'; //Or what ever id name do you have.

This error may occur if you are trying to use laravel-mongodb with custom increment and unique generated id rather than the default _id from MongoDB. The solution in this case is not to name your custom id like this 'id' because it will make Laravel confused. However, name it anything else.

answered Sep 21 '15 at 11:34

abdawoud

219
4
16

I am facing same problem, I am using `laravel-mongodb`. I tried the solutions given in the comments but no success. Is there any other solution for it? – tejashsoni111 Sep 28 '15 at 10:14
thank you sooooo much for saving me a lot of time, would've taken me ages to figure this one out – J.Pip May 03 '17 at 12:16
My GOD !!!!! I WANT TO PERSONALLY THANK YOU .... AFTER SIX HOURS .. YOU FIXED MY ISSUE . THANKS A LOT !!!!!!!!!!!!!!!! – Neeraj Verma May 05 '20 at 11:10

score 0 · Answer 2 · answered Nov 30 '19 at 22:07

for those who still have this problem, if your primary key doesnt follow autoIncrement, you should add this following code to your User model:

public $incrementing=false;

and if you have changed your primary column name, add this:

protected $primaryKey = 'vid'; //changed to vid

Laravel's Auth::attempt() returns true but Auth::check() returns false

2 Answers2

Linked