Add support & documentation for integrating with Lumen 5.2

[rajabishek]

Since Lumen does not support session state, incoming requests that we wish to authenticate must be authenticated via a stateless mechanism such as API tokens. This package is really going to be helpful for resolving out the authenticated user from the request through API token.
https://lumen.laravel.com/docs/5.2/authentication

Auth::viaRequest('api', function ($request) {
    try {
        if (! $user = JWTAuth::parseToken()->authenticate()) {
            return null;
        }
    } catch (Exception $e) {
        return null;
    } 
    return $user;
});

It would be really helpful if we have another section in the wiki about integrating this package with Lumen. I see that most of the work has already been done ( already there is a LumenServiceProvider ), only that it needs to be upgraded to support v5.2 and documented. Thank you Symon for giving us this wonderful package that we can use with out Laravel and Lumen projects.

[syropian]

@rajabishek Where do we put this Auth::viaRequest function? And what exactly is api here?

Edit: Ah I see that the block is already in the AuthServiceProvider, but I still don't quite understand what the api portion represents.

Edit again: Looks like it's a "driver"

public function viaRequest($driver, callable $callback)
    {
        return $this->extend($driver, function () use ($callback) {
            $guard = new RequestGuard($callback, $this->app['request']);

            $this->app->refresh('request', $guard, 'setRequest');

            return $guard;
        });
    }

[syropian]

Weird, $user always return null for me. It's the null from the if statement, not the catch though.

[rajabishek]

@syropian The AuthServiceProvider in Lumen 5.2 already has a call to Auth::viaRequest method that accepts a Closure which will be called when the incoming request needs to be authenticated ( if auth middleware is used ). Within this Closure, we may resolve out App\User instance however we wish. If no authenticated user can be found for the request, the Closure should return. So what I was suggesting was if we use this package with Lumen 5.2 then we would have to do something along the lines of

Auth::viaRequest('api', function ($request) {
    try {
        if (! $user = JWTAuth::parseToken()->authenticate()) {
            return null;
        }
    } catch (Exception $e) {
        return null;
    } 
    return $user;
});

And now once this is done, in our controllers or route handling closures we can directly get the authenticated user using the Auth::user() or through $request->user() just like how we would deal with sessions. Something like

use Illuminate\Http\Request;

$app->get('/post/{id}', ['middleware' => 'auth', function (Request $request, $id) {
    $user = Auth::user();
    //or
    $user = $request->user();
}]);

So I just felt there must be a separate section in the wiki that needs to have this documented on how we can integrate and use this package with Lumen apps and specifically with v5.2.

[syropian]

@rajabishek I tried setting mine up just like your example above, but JWTAuth::parseToken()->authenticate() is always null. I verified that the jwt token is present in the request but the authenticate method can never seem to fetch a user. Any ideas?

[rajabishek]

@syropian If you had used a similar code in the AuthServiceProvider that I had written above, then probably null might be returned because there is some exception beign thrown. Just remove the exception handler and probably we can get to see where the error is. Give this a try.

[syropian]

@rajabishek I actually tried that by just doing a really simple version like so:

Auth::viaRequest('api', function ($request) {
    $user = JWTAuth::parseToken()->authenticate();
    return $user;
});

but it's not returning a user (or a useful error). It's weird because I am able to generate the token for a given user no problem, but just can't get it to work the other way around! :c

[rajabishek]

@syropian Try doing this.

Auth::viaRequest('api', function ($request) {
    JWTAuth::parseToken();
    $token = JWTAuth::getToken();
    dd($token);
});

Just to run a check whether the package is actually able to grab the token from the request. If $token happens to be null, then we now know that there is some problem with the getting the token from the request headers, if so we can try setting the token explicitly by grabbing the Authorization header first and then the token value from that. Then we can set the token on the JWTAuth instance through the JWTAuth::setToken($token); method. Before doing all this I would recommend to actually check once whether the request has the Authorization header. If there is no Authorization header then it could be a problem with Apache also. Reference: #200

[syropian]

@rajabishek Yup, I did check for that, the token is indeed present in the header.

Anyway, I changed my code up a bit to ensure it returned null if the user wasn't present, and I get a 401 (unauthorized) response now. Clearly that means null is being returned from Auth::viaRequest(). No idea why.

Auth::viaRequest('api', function ($request) {
  if( !$user = JWTAuth::parseToken()->authenticate() ){
    return null;
  }
  return $user;
});

and in my routes I have:

$app->post('document/create', ['middleware' => 'auth', function(Request $request, $id) {
    $user = Auth::user();
    dd($user);
}]);

I've made sure to enable the auth middleware in my app.php file.

[rajabishek]

@syropian You have the AuthServiceProvider service provider uncommented in your bootstrap/app.php file right to make sure it is registered ?

[syropian]

@rajabishek yup!

[syropian]

@rajabishek There isn't something internal that relies on the User model being in in the App\User namespace is there? I prefer to keep all my models in App\Models\Whatever namespace. I've updated the jwt-auth config to use this, and also updated the namespace in AuthServiceProvider. I assume it works fine at least one way as I'm able to generate a jwt token no problem.

[tdhsmith]

I tried setting mine up just like your example above, but JWTAuth::parseToken()->authenticate() is always null.

Yeah check out my response in #384. You're using the stock Lumen setup, which creates an auth driver called api, which will be supported by RequestGuard (and the callback you pass to it in viaRequest). But the default jwt-auth setup has authenticate() calling Auth::onceUsingId(), which is not supported on RequestGuard, so you're going to get some sort of illegal method error.

There are a couple of solutions that I mention there:

1. Don't use authenticate (or its alias toUser), and define a viaRequest callback that works some other way ($payload = JWTAuth::getPayload() and then manually find the user from the sub claim with something like App\Models\Whatever\User::find($payload['sub'])). If you go this route, you'll also have to find a workaround for attempt, if you use it.
2. Define a custom jwt-auth auth provider that doesn't rely on Laravel's Guards. The byId will basically be what I wrote in (1). The byCredentials depends on your needs, but will likely have to be capable of both finding a user by arbitrary credential queries AND validating the credentials (i.e. password hashing). Check out EloquentUserProvider's implementation of those functions, for example.
3. Ultimately I think jwt-auth is going to be implemented as an auth driver for 5.2 and beyond, so instead of using the AuthServiceProvider at all, you'll just change your auth config to use driver jwt. You're more than welcome to help implement that change. 😉

[tdhsmith]

Actually you might even be able to get by with changing the auth driver to session and then using the provided middleware as normal... jwt-auth doesn't actually require any of the session-y aspects of the driver, so I don't think it would fail...?

[irazasyed]

Here's a package i created (Auth Driver) - https://github.com/irazasyed/jwt-auth-guard

For this package. Took me some time to play around with the code due to lot of various issues but at the end it was worth it.

Works like a charm.

P.S Obviously it would be good if the official package implements the Auth Driver.

[syropian]

@irazasyed That's awesome! Thanks a lot :)

@tdhsmith I ended up parsing the payload manually, and that worked just fine, thanks for the help :)