[semi-solved] (1.7.5.1) In which file(s) to extend authorization behavior as to handle an alternative encryption?

[defurav]

Hi.

I have a classic migration problem: in the store from which I import data, passwords are encrypted by plain MD5. So I need to inject a password reencryption procedure on login attempts. That is, first received password must be compared to MD5 value, upon success in which the MD5 value is deleted from the database and received password is encrypted using Presta's own procedure.

My question is, if there are people who've already written this, which files did you have to modify, which classes/methods did you extend?

Thank you.

Edited March 26, 2019 by defurav (see edit history)

[defurav]

The place I am looking for may be narrowed down as the last place in the call stack that the password still occurs in unencrypted form (that is, as entered by the user). It's at that point that I would insert code that would verify that password with respect to the old database and set it as the user's ordinary password (now in accordance to Presta's encryption procedures and database location), so that regular Presta authentication would then proceed without disruption.

Anyone?

Edited March 26, 2019 by defurav (see edit history)

[defurav]

Excuse my multiple replies.

I realized that I don't need the password's last occurrence; I just need an occurrence of it that is accompanied by an indication of the user's identity, such as their e-mail. If I have those two pieces of data, for presence of which in $_POST I may test anywhere, even in index.php, I may do the verification with respect to the old database before authentication proper even starts.

If someone knows the proper place to do this (in particular as to avoid overwriting at Presta updates; perhaps I'll place the check in code auto-prepended through .htaccess if it would persist), please share, but I'll leave the above for anyone facing the same conundrum.

Edited March 26, 2019 by defurav (see edit history)

[JBW]

I guess hook actionAuthenticationBefore could be the right place.

See https://devdocs.prestashop.com/1.7/modules/concepts/hooks/list-of-hooks/

Quote

actionAuthenticationBefore

Before a customer successfully signs in

Located in: /classes/form/CustomerLoginForm.php

 

[defurav]

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?

Edited March 27, 2019 by defurav (see edit history)

[JBW]

1 hour ago, defurav said:

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

These are not touched by upgrades.

 

1 hour ago, defurav said:

(I think, although I may be wrong, that employing hooks requires writing a module, which seems a bit excessive in my particular case

Yes this required a module. Excessive I dont think as you can generate the sceleton easily with Prestas Module Generator. Anyway good to hear that you found a solution that works for you