5.2/5.3 - Auth::setUser() not creating user session

Hi All, I have a few different sites/domains and working to share some user information when a user clicks a link between the sites. I created a middleware class to check if the URL variable exists and to merge the user info -- technically a JWT token (tymons jwt plugin) but wouldn't think that would matter. After decoding and ensuring the token is correct, then the logic is performed and the user session is created.

I did have to make some tweaks to my User model so that the $user was in the correct Authenticatable format but it isn't throwing any errors -- BUT no session is truly created. When I click on a link/route that is using an "auth" middleware, then it throws me back out to login again.... purpose of the URL token is to log in the user.

Here is my middleware class

<?php

namespace App\Http\Middleware;

use Closure;

use Event, JWTAuth;
use App\User;
use App\Tpperson;
use Illuminate\Support\Facades\Auth;


class checkJWT
{
    
    public function handle($request, Closure $next, $validateAll = false) 
    {   
        if ($request->has('jwt') && !Auth::check()) {
            $token = $request->jwt;

            $jwtObj = JWTAuth::setToken($token)->getPayload();

            $tpPID = 0;
            if (is_numeric($jwtObj->get('sub')) && $jwtObj->get('sub') > 0) {
                $tpPID = $jwtObj->get('sub');
            }

            if ($tpPID > 0) {
                $user = User::find($tpUserExists);
                Auth::guard('web')->setUser($user);

                dump(auth()->check());
            }

            dump(Auth::check()); 

            // fire off event to hit up Auth::setUser to be sure
            Event::fire('tymon.jwt.valid', array($user));
        }

        return $next($request);
    }
}

My route or web.php (laravel 5.3 route file) has this:

Route::group(['middleware' => ['web','auth.jwt']], function () {
    Route::get('/features', array(
        'as' => 'features',
        function() {
            return view('features')->with('teaserPadding', 60);
        }
    ));
});

FYI, I have tried flipping around the order of the 'web' and 'auth.jwt' and only using 'auth.jwt' but that doesn't make a difference in the result --> session not saved.

I have tried the Auth::setUser several different ways too - with guard and without but neither truly logs the user in.

Auth::guard('web')->setUser($user);

Auth::setUser($user);

CRAZY thing is my Auth::check() all return true during that "page request" which seems to mimic Auth::once but I do NOT want a "stateless api".

Ways to ensure Auth::setUser() creates the user's session? Code missing - class or remember me token? Yes, I have tried on Laravel 5.2 and 5.3.

Thanks! Jeremy

Connor-S-Parks

9 years ago

Level 8

Auth::setUser() doesn't touch your session, that's why. You want to instead be calling Auth::login($user).

See: https://github.com/laravel/framework/blob/5.3/src/Illuminate/Auth/SessionGuard.php#L732-L740 and https://github.com/laravel/framework/blob/5.3/src/Illuminate/Auth/SessionGuard.php#L441-L460

1 like

jab1000

9 years ago

Level 2

Hi Connor,

Hmmm - I tried Auth::Login($user) too and unfortunately same result (not logged in fully). Digging through the SessionGuard.php it shows the login calls fireLoginEvent:

protected function fireLoginEvent($user, $remember = false)
    {
        if (isset($this->events)) {
            $this->events->fire(new Events\Login($user, $remember));
        }
    }

FYI, I previously had Auth::loginUsingId which also fires off the login() function -- it had same result (no session created) as this which is another reason why the login isn't working.

My hunch now is that $this->events is NOT set then? Thoughts on how to set it so that it fires off?

Thanks!

jab1000

9 years ago

Level 2

I decided to edit the SessionGuard.php directly and add in some logging to see what is set or not. Yes, $this->events is being previously and the login event is fired off.

The weird thing to me is in the "/storage/framework/sessions" folder their are multiple session files based off the URL loading -- pretty much like EACH URL request creates a new file. The "cookie" (login_web_59ba36addc2b2f9401580f014c7f58ea4e30989d) seems to be the same in each (assuming that is the variable since it was logged here:

protected function updateSession($id)
    {
        Log::info($this->getName()); // login_web_59ba36addc2b2f9401580f014c7f58ea4e30989d
        Log::info($id); // users.id 
        
        $this->session->set($this->getName(), $id);

        $this->session->migrate(true);
    }

New thoughts?

severfire

9 years ago

Level 1

i think it should be treated as some sort of bug, also looking for solution to problem called '" Auth::loginUsingId not persisting in middleware - "'

xCode195

7 years ago

Level 1

Sorry to revive an old thread but did anyone solve this? I am currently facing the exact same issue as I am authenticating users in Lumen using OAuth for the actual API (works fine) and I am trying to add session auth for documentation access.

The session authenticates fine with Auth::attempt() and Auth::check() returns true for the duration of the request. As soon as I redirect the user, the session is gone, Auth::check() returns false and I am thrown back to the login page. There is a new session file for everytime I tried to login. I can see the session cookie is set properly to the last session attempt. Also the session file is missing some things like password hash when I compare it to a Laravel session file which leads me to think it's not actually setting some values properly.

Using Lumen 5.6

Edit:

When I use dispatch:

$proxy = Request::create(
                'api/documentation',
                'get'
);

return app()->dispatch($proxy);

Auth::check() works but i get stuck on the ogin route, not directed to the actual api/documentation route....

Please or to participate in this conversation.