Edit History

Thanks, JBW. I understand that that hook really means "before authentication", and not literally "before successful authentication", because I think that the latter wouldn't do; for successful authentication, performing the password switch is a precondition.

Maybe someone will use a hook if they choose to make a module to do this (I think, although I may be wrong, that employing hooks requires writing a module, which seems a bit excessive in my particular case). Meanwhile, here is my current approach. I decided to place the password switch code in the constructor of a class I overrode that appears to be instantiated early and commonly.

/override/classes/Customer.php

<?php

class Customer extends CustomerCore
{
    function __construct()
    {
        call_user_func_array([$this, 'parent::__construct',], func_get_args()); // future-proof?
        
        call_user_func(function()
        {
        $mail = isset($_POST['email']) ? $_POST['email'] : null;
        $pass = isset($_POST['password']) ? $_POST['password'] : null;
        if(!($mail && $pass)) return;
        $pass_enc1 = md5($pass);
        $pass_enc2 = Tools::hash($pass);
        
        // pseudocode
        if(query('select from users_old where mail = mail and pass = pass_enc1'))
        if(query('update users_new set pass = pass_enc2 where mail = mail'))
        if(query('update users_old set pass = none where mail = mail'))
        ;
        });
    }
}

?>

By the way: would you happen to know if such overrides (in /override dir) are overwritten/erased upon Presta updates?

Thanks, JBW. I understand that that hook really means "before authentication", and not, strictly speaking, "before successful authentication", because I think that the latter wouldn't do; for successful authentication, performing the password switch is a precondition.

Maybe someone will use a hook if they choose to make a module to do this (I think, although I may be wrong, that employing hooks requires writing a module, which seems a bit excessive in my particular case). Meanwhile, here is my current approach. I decided to place the password switch code in the constructor of a class I overrode that appears to be instantiated early and commonly.

/override/classes/Customer.php

<?php

class Customer extends CustomerCore
{
    function __construct()
    {
        call_user_func_array([$this, 'parent::__construct',], func_get_args()); // future-proof?
        
        call_user_func(function()
        {
        $mail = isset($_POST['email']) ? $_POST['email'] : null;
        $pass = isset($_POST['password']) ? $_POST['password'] : null;
        if(!($mail && $pass)) return;
        $pass_enc1 = md5($pass);
        $pass_enc2 = Tools::hash($pass);
        
        // pseudocode
        if(query('select from users_old where mail = mail and pass = pass_enc1'))
        if(query('update users_new set pass = pass_enc2 where mail = mail'))
        if(query('update users_old set pass = none where mail = mail'))
        ;
        });
    }
}

?>

By the way: would you happen to know if such overrides (in /override dir) are overwritten/erased upon Presta updates?

Thanks, JBW. I understand that that hook really means "before authentication", and not, strictly speaking, "before successful authentication", because I think that the latter wouldn't do; for successful authentication, performing the password switch is a precondition.

Maybe someone will use a hook if they choose to make a module to do this (I think, although I may be wrong, that employing hooks requires writing a module, which seems a bit of an overkill to me). Meanwhile, here is my current approach. I decided to place the password switch code in the constructor of a class I overrode that appears to be instantiated early and commonly.

/override/classes/Customer.php

<?php

class Customer extends CustomerCore
{
    function __construct()
    {
        call_user_func_array([$this, 'parent::__construct',], func_get_args()); // future-proof?
        
        call_user_func(function()
        {
        $mail = isset($_POST['email']) ? $_POST['email'] : null;
        $pass = isset($_POST['password']) ? $_POST['password'] : null;
        if(!($mail && $pass)) return;
        $pass_enc1 = md5($pass);
        $pass_enc2 = Tools::hash($pass);
        
        // pseudocode
        if(query('select from users_old where mail = mail and pass = pass_enc1'))
        if(query('update users_new set pass = pass_enc2 where mail = mail'))
        if(query('update users_old set pass = none where mail = mail'))
        ;
        });
    }
}

?>

By the way: would you happen to know if such overrides (in /override dir) are overwritten/erased upon Presta updates?

Thanks, JBW. I understand that that hook really means "before authentication", and not, strictly speaking, "before successful authentication", because I think that the latter wouldn't do; for successful authentication, performing the password switch is a precondition.

Maybe someone will use a hook if they choose to make a module to do this. Meanwhile, here is my current approach. I decided to place the password switch code in the constructor of a class I overrode that appears to be instantiated early and commonly.

/override/classes/Customer.php

<?php

class Customer extends CustomerCore
{
    function __construct()
    {
        call_user_func_array([$this, 'parent::__construct',], func_get_args()); // future-proof?
        
        call_user_func(function()
        {
        $mail = isset($_POST['email']) ? $_POST['email'] : null;
        $pass = isset($_POST['password']) ? $_POST['password'] : null;
        if(!($mail && $pass)) return;
        $pass_enc1 = md5($pass);
        $pass_enc2 = Tools::hash($pass);
        
        // pseudocode
        if(query('select from users_old where mail = mail and pass = pass_enc1'))
        if(query('update users_new set pass = pass_enc2 where mail = mail'))
        if(query('update users_old set pass = none where mail = mail'))
        ;
        });
    }
}

?>

By the way: would you happen to know if such overrides (in /override dir) are overwritten/erased upon Presta updates?