User model best practices

We use a model like UserRoles as a type of relationship for something like that. This way you can expand on the roles and have multiple roles per user.

Until you get well acquainted with the authorization I would stick with the way Taylor does it out of the box.

After all the firefighter never sees the word user that's in the code.

After you learn it well then you can start customizing, this is just my opinion.

I echo what @jlrdw says, also keep in mind that a lot of the functionality in deeper parts of the auth are not directly relayed to you when creating the authentication scheme for the first time using the make::auth command.

An example of this is customizing the password reset logic and so forth.

Before I would ever start customizing (which I have), run through a hello world app with what you are trying to customize before placing the customization's into a development app.

Also, you can always pull in information from other models and especially with the hasOneThrough() or hasManyThrough().

You could perhaps stick with the User model, and use it for authentication, but then create a Firefighter model which extends User.

It does not need to contain any functionality if you don't want, but it could contain relationships etc.

eg;

<?php

namespace App;

use App\User;

class Firefighter extends User
{
    public $table='users';
}

Thanks everyone for the responses. I'm going to do a little bit of playing around. I like @snapey 's suggestion because it may make future code upgrades a bit cleaner than shoving a bunch of extra functionality directly on the User model, I can put it in the Firefighter model while still maintaining the default auth behavior.

I really appreciate the feedback!