Support the ongoing development of →
Installation Configuration
Last updated 2 years ago.

Laravel is surely capable of what you're looking to do, though it has a bit of a learning curve for a project of that size. That said, any framework you'd choose to go with would have a learning curve.

Hooking Laravel up to an existing database is reasonably straight forward and easy, as is reading from the JSON files. Depending on how your login info works, that may not be as straight forward. Laravel has a good auth system out of the box which works well. If you want to modify it to hook up to an existing auth system, getting everything working can potentially be time consuming (though it's generally not too bad).

To integrate Laravel with an existing auth system you'll need to create a custom PasswordBroker. What you need to do exactly will depend on how the user password gets to the server, and how it's hashed/salted/etc.


Hi @Justin - thank you, and my apologies for delayed reply, I didn't see the reply before.

Would it be the case that possibly the easiest thing would be to just invalidate all current password fields and force returning users to create a new password, in effect switching them over to the Laravel auth system?

To be honest, I currently get very few "backend" logins from the information providers to update, as their info doesn't change much, and there's no login required for listeners.

The backend template is very basic (see below, I just knocked it up in Bootstrap 3 in 2014!) But it is accessible for screenreader users and any replacement needs to be, too. What do I need to add NOW to ensure painless growth? Spark? Nova? Lumen? They all look like candidates.

I think, in my mind, I've now made the decision to go Laravel. Just need a steer with the right plugins! Wish me luck! :)

Backend example


I can't speak much to Spark or Nova as I've never really used them.

Nova is a spiffy package from the bit I've played with it. However, it seems to be more geared towards being an Admin panel, and doesn't look like it'd be a good fit for a user interface.

I haven't used Spark, but it looks to be geared towards billing and payments. If you take payments it might be a good time savings to just purchase Spark.

Lumen is mostly just Laravel Lite. Or Laravel Double-Speedy-Quick. It's a micro framework geared fully for speed, at the expense of some other niceties. For the most part, I feel Laravel is plenty fast, as long as it's set up right (good caching, no crazy queries, etc; things that can cause problems for any framework). If you do decide to go with Lumen, you can always convert your project to Laravel by dropping your Lumen files into a Laravel project.

As it relates to the easiest way to switch over passwords in a security conscious manner without modifying Laravel defaults, it's probably easier to generate the hash Laravel expects (defaults to Illuminate\Hashing\BcryptHasher.php) before switching to Laravel, and storing that in your database as a new, separate field. However, this would require that a user login during the period before you switch so you can generate the hash. If they didn't, they'd have to go through the password recovery process after the switch.

The alternative is to tell Laravel to hash the passwords the same way you do in your current system. If you're alright with using the default Laravel login system (ex password recovery), you can create a custom Hasher that would allow Laravel to use your existing password hashes. It may sound a bit intimidating, but it's really not too bad.

  • Create a ServiceProvider for your own custom Hasher
  • In the register method, extend Manager by calling Manager::extend();
    • The Manager extend will load up the customer Hasher you'll create
  • Update config/hashing.php to tell Laravel to use your Hasher

The customer Hasher route is the way I'd go. If you want to phase it out later to be as Laravel-y as possible, you'll have more flexibility in time frame and how you want to go about it.


Thank you so much! And I think I'm already using bcrypt, because the previous "mini" MVC I was using has:

$user_password_hash = password_hash($_POST['user_password_new'], PASSWORD_DEFAULT, array('cost' => $hash_cost_factor));

And from I see that would be producing bcrypt hashes.

So, all good!


If anyone else wants to chip in regarding the back end admin, then please do so!


If that’s the case, you may only need to update the ‘cost’ in the hashing config to match your current. :D


Sign in to participate in this thread!


Your banner here too?

Jonathan talkingnews Joined 7 Nov 2018


We'd like to thank these amazing companies for supporting us

Your logo here?

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 - All rights reserved.