17

I created a new Lumen 5.4 project and tried to seed some data. In the seeder, I used bcrypt to hash the password. But when I run php artisan db:seed, I get this error:

Call to undefined function bcrypt()

Why can't I use bcrypt in Lumen? I have used it in Laravel previously.

Cœur
  • 37,241
  • 25
  • 195
  • 267
JackSlayer94
  • 805
  • 3
  • 16
  • 38

5 Answers5

46

You could try:

app('hash')->make('yourpassword');
Amr Aly
  • 3,871
  • 2
  • 16
  • 33
  • True, this is more or less a workaround of the bcrypt implementation but why not use it directly? – JackSlayer94 Mar 08 '17 at 06:06
  • 1
    really i don't know but what i know is `bcrypt()` in its source code returns this `return app('hash')->make($value, $options);` – Amr Aly Mar 08 '17 at 06:10
  • 1
    Okay thanks! Might be worth adding that this is a work around so people will be aware of it. – JackSlayer94 Mar 08 '17 at 06:11
  • Is there any way to get hash key. Actually, I took over someone's project and now getting same error and now the previous developer is not responding. And I know what is encrypted key generated as I have access to database. – Tanish bansal Jan 09 '21 at 15:01
14

another solution would be to use Facades\Hash

use Illuminate\Support\Facades\Hash;

code

'password' => Hash::make('your_password')
9

Try to do it this way

'password' => password_hash('123456', PASSWORD_BCRYPT)
krrskl
  • 91
  • 2
  • 5
-1

try, I can do it fine in my project

 function bcrypt($value, $options = [])
        {
            return app('hash')->make($value, $options);

        }
Bonny Ham
  • 9
  • 1
-2

As you mentioned, bcrypt() doesn't exist in Lumen. As another workaround, since you mentioned seeding in Lumen, you could just use this in \Faker\Generator for the password: $faker->password

kakoma
  • 1,179
  • 13
  • 17
  • Yeah, so you will not know the generated password and you will not be able to test the script using the generated users. Nope. – Sergiu Nov 08 '17 at 17:01
  • @Sergiu There are a number of use-cases where you aren't going to login with the generated users; I believe this option is a viable one especially in those scenarios. The question asked actually didn't restrict the need to test the script using the generated users so this approach is valid. – kakoma Nov 09 '17 at 20:40
  • I do not agree, in a testing/dev environment it's always a good practice to use the same password for all users, for obvious reasons. In a production environment, you would not use Faker. – Sergiu Nov 11 '17 at 13:35