Sentinel::setHasher seems to get overwritten

[spaceemotion]

I'm currently transitoning an old application in which I need the CallbackHasher. I am using Laravel 5, so I put the Sentinel::setHasher() in my ApplicationServiceProviders boot method.

Later on (in a login form) the hasher somehow gets set to the NativeHasher again - I checked this by various dd calls.

How can this be? do I need to set the custom hasher in a different provider? I'm currently not able to log in at all.

[brunogaspar]

Is your ApplicationServiceProvider being added after the Sentinel service provider?

I did a quick test and the hasher i set seems to be set properly before and after i try to log a user in via login or authenticate methods.

[spaceemotion]

Yes, my service provider is after the SentinelServiceProvider:

    'providers' => array(
        // ...

        /*
         * Additional providers
         */
        'Cartalyst\Sentinel\Laravel\SentinelServiceProvider',
        'Barryvdh\Debugbar\ServiceProvider',

        /*
         * Application Service Providers
         */
        'Appp\Providers\AppServiceProvider', //<-- that one

    ),

My boot method currently looks like this (using dd to check if it reaches that code):

    /**
     * Bootstrap the application services.
     *
     * @return void
     */
    public function boot()
    {
        Sentinel::setHasher(new CallbackHasher(
            function($value)
            {
                return Hash::make($value);
            },

            function($value, $hashedValue)
            {
                dd([$value, $hashedValue]);
            }
        ));
    }

[suwardany]

Seems to be working fine here using your exact same setup, and it does dump on authenticate

[spaceemotion]

This is my controller's method code; maybe I am doing something wrong here even:

    public function postLogin(Request $request)
    {
        $credentials = $request->only('email', 'password');

        try {
            // Authenticate with our credentials, if it succeeds continue to the home screen
            if (Sentinel::authenticate($credentials, $request->has('remember'))) {
                return redirect()->intended(route('home'));
            }

        } catch(NotActivatedException $ex) {
            return redirect('/auth/activate');
        }

        // ... otherwise return to the login page
        return redirect('/auth/login')
            ->withInput($request->only('email', 'remember'))
            ->withErrors([
                'email' => 'Invalid credentials / No user found',
            ]);
    }

I am also wondering why the system would let me log in with an email, but not with a username. I already changed the Users $loginNames to ['email', 'username'];. Very strange…

[suwardany]

Copied that over and defined the route and it's working as well.

[spaceemotion]

Okay, so I did some more testing and it seems like the closure for the "sentinel.hasher" in the SentinelServiceProvider gets definitely called before my Sentinel::setHasher() method. But when I do a dd in my controller method it somehow was set to the NativeHasher once again.

I just tried to move the setHasher method to my register() function in the ServiceProvider and that time the Sentinel one was called after my custom one (I haven't changed the order of my providers).

Digging further I found out that the SentinelBootstrapper gets executed after my service provider, and creates a sentinel instance with the default hasher.

Is there a way to work around this? It really is weird that it seems to work on the setup everyone else but mine.

[suwardany]

@spaceemotion are you using the correct alias?

[suwardany]

The SentinelBootstrapper is only triggered by the Native facade, apparently that is being used on your application which is wrong.

Laravel applications should be using the Laravel facade, Cartalyst\Sentinel\Laravel\Facades\Sentinel

[spaceemotion]

Oh crap, didn't think about that. Yes I indeed used the 'Native' one, well - thanks for the hint!

That still doesn't fix the username issue. Logging in through an email works, but when using a username the system still gives off an error (as explained above). I checked the query object that gets executed and it seems like Sentinel tries to get an email with the given username. Is there a way to decide which field to use on which occasion (if the name contains '@', then use 'email', otherwise 'username')?

[suwardany]

You can pass in login instead of explicitly stating email or username, that will work for both fields if they're defined on the loginNames array.