CODEWITHSUNDEEP
laravelrethinkdblaravel-5
mtpultz
mtpultz

Reputation: 18248

Laravel 5.2.14 with Duxet/RethinkDB Authentication Redirect User Seen as Guest in Home Route

Using a clean install of Laravel 5.2.14, adding the migration and seed files, adding the auth scaffolding using artisan make:auth, and running this using MySQL, and finally logging into the dashboard works as usual, but when I add Duxet/RethinkDB; update the migration, seed, and User model; and attempt to login it no longer redirects to /home, but back to /login. You can see in the network tab of Chrome that /login gets a 302 error, /home gets a 302 error, and it returns to /login indicating an issue in the middleware of the home route.

login   302 text/html
home    302 text/html
login   200 document

No exception is thrown or error logged, but stubbing through the Auth middleware using Monolog (/app/Http/Middleware/Authenticate). The statement Auth::guard($guard)->guest() always returns 1 indicating that the user is a guest causing the redirect, but it appears to authenticate the user from stubbing through AuthController's AuthenticatesAndRegistersUsers child trait AuthenticatesUsers::login. So clicking home in the navigation just redirects to the login since the home middleware indicates the user is a guest.

public function login(Request $request)
{
    $this->validateLogin($request);

    ...

    if (Auth::guard($this->getGuard())->attempt($credentials, $request->has('remember'))) {

        Log::info('Successful Login!'); // Always gets here

        return $this->handleUserWasAuthenticated($request, $throttles);
    }

    Log::info('Failed Login!'); // Never gets here

    ...

If I revert to the previous commit that uses just MySQL this all works, and the user is redirected to the dashboard. I've been stubbing my way through the web middleware group, auth middleware, and AuthController traits; trying to figure this out with no luck.

Has anyone run into this and can point at a potential solution?

Upvotes: 2

Views: 286

Answers (1)

mtpultz
mtpultz

Reputation: 18248

After more than a couple hours of trying to figure this out by stubbing and paring down the code I eventually noticed an ID of a user that was too big for the number of users I had seeded, which turned out to be the integer part of a truncated UUID.

The issues arose from how the Duxet/RethinkDB package was implemented, which doesn't use the Blueprint methods that Laravel implements when building statements for a typical migration with an auto-incrementing ID:

use duxet\Rethinkdb\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class CreateUsersTable extends Migration {

    public function up()
    {
        Schema::create('users', function(Blueprint $table) {
            $table->increments('id'); // Won't be an auto-incrementing unsigned integer
            ...
        });
    }

    ...
}

and seed:

use Illuminate\Database\Seeder;

class UserTableSeeder extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        // Developer accounts
        factory(App\User::class, 'admin', 1)->create([
            'username' => 'test',
            'email' => '[email protected]'
        ]);
}

NOTE: I'd like to note that there isn't anything wrong with Duxet/RethinkDB package. This is just something to be aware of when attempting to implement it in Laravel.

Duxet/RethinkDB uses a concise way to create a table without invoking Laravel's API for methods like increments, which handles assigning an unsigned integer to ID columns. A ReQL statement r.db('app').table('users') results indicate a UUID being assigned for the ID columns that would normally be an auto-incremented unsigned integer by Laravel.

{
"created_at": Fri Feb 12 2016 10:04:22 GMT+00:00 ,
"email": [email protected], »
"id":  "8bbc1c35-6be5-4b1f-87de-75eba1c459eb" ,
"password":  "$2y$10$2f7QjuBCjEMr3R01ZNlwI.ft8v8FYs8IHRQzPI1lKdojIXtK7b9wO" ,
"role":  "admin" ,
"updated_at": Fri Feb 12 2016 10:04:22 GMT+00:00 ,
"username":  "test"
}

In order to overcome set incrementing to false, which will stop Laravel from casting the UUID into a PHP integer data type, which truncates the UUID. I've submitted a PR to make a few changes to the Duxet/RethinkDB package to prevent others from having to discover this for themselves.

Upvotes: 0

Related Questions