Introduction

In my day job, we make good use of Laravel's authentication quickstart via php artisan make:auth, but our next step is to always remove the user registration component. As most of our applications are internal, or for clients that we manage, we're not running applications that openly accept new users.

In order to get around this in the early stages, it usually involves me creating user accounts by logging into the server via SSH and running php artisan tinker to manually create an App\User model. This works when it's one or two accounts, but as the applications grow and we start to introduce our service management team, using this approach unravels quickly.

Simplifying the process

A good middle ground for this situation, I feel, is a small package that is a little more convenient. Upon installing and registering the service provider, you'll be given a new make:user command, which allows you to quickly whip up a new application user from the command line.

For developers and our more technical management team, this approach allows us to introduce new users to the application while we're still building it out and getting feedback. Our general process, once we create the user with a random password, is to send them a link to the site and have them perform a password reset.

Using the make:user command

1php artisan make:user [email protected]

When you run this command, a new account with a random 32 character password will be generated, and Laravel's default password reset notification will be sent to the user to perform the rest. This wraps up our manual process into a short and easy to use command.

Of course, when you're creating an account for yourself in a new application, you can specify your own password using the --password option. When doing so, you can also use the now optional --send-reset option. When creating an account for myself, I don't need to go through the password reset flow.

From time to time, we also customise Laravel's default users table with additional fields. For example, we might add a boolean admin flag to the database. In order to set any extra parameters, you can use the --fields option, providing a comma-separated list of key value pairs like so:

1php artisan make:user [email protected] --fields="admin:true"

There is some basic handling for boolean and null values, in particular, to ensure that they are stored and retrieved from the database correctly.

Conclusion

On episode 30 of the North Meets South Web Podcast, Jake and I discussed the possibility of making the package configurable. After subsequently exploring the possibilities, I decided to leave this configuration for now as it gets a little tricky to manage the default cases and fields, as well as being flexible enough to facilitate many possibilities.

For example, the name field is not nullable by default with the users table migration, so I ran into some issues accounting for that when customising the model and more still when customising the username field. This was exacerbated further by the fact that Jake's example of API-only users likely wouldn't have a username, name and password, but likely just a description and token.

If you have any thoughts on providing this flexibility, I'd be happy to hear them or - better yet - open a pull request on the repository.