Hello,
I have migrated my customers using the pro tool, all customers are present in the admin grid and database. I can also see that the corresponding password hash has been added to the M2 table: customer_entity however, for some reason the password in the M2 field has added two characters at the end of the password hash:
:0
Also, I have tested multiple passwords and they do not work on the frontend either. We have not rehashed to SHA-256 yet but it is my understanding that MD5 should work fine too in M2.
Note we have also double checked the correct store is set to default.
Please advise how we can go about fixing this?
-
genesiscommerce ⋅950.00 $tone July 22, 2019
An update,with some further testing removing the charactors from the field make the password work so this is the issue.However, I am using the delta mode and with a large data set so it is not enough to simply remove it from all fields, the delta will just bring them back again.Do you know why the tool is adding these charactors?
genesiscommerce ⋅950.00 $tone
July 22, 2019
30 answers
I notice that your code does this, but I don’t understand why?
//we have to do this, because the Magento CE 2.0.0 or later was change method to hash password: md5() -> sha256()
if ($table == 'customer_entity_varchar' AND $attributeCode1 == 'password_hash') {
$customer2->$attributeCode1 .= ":0"; // In Magento2: 0 is HASH_VERSION_MD5
}
Hi there,
Do you know why the tool is adding these charactors?
That suffix is to notify Magento 2 that is a password encoded by MD5 function (password version 1 in Magento 2).
All our users did migrate customer’s data successfully so far. It seems your instance has some special cases.
Please re-check further at your end and make sure that the migrated website (website related to the migrated customer) was set as default website of your M2 instance.
If the issue still persists, then let me know here.
Regards,
Mall.
Hello,
This issue still persists 3 months later and we are no closer to finding a fix. Customer passwords don’t work following our migration with you.
See here: https://github.com/magento/magento2/issues/3758 It seems we are not the only ones experiencing this issue.
To repeat, with a :0 on the end (md5) it doesn’t let customers login. Removing it does.
Please advise asap with a fix for this.
Hi there,
Lets provide me information about your instance:
+ URL and Admin credentials of your site
+ SSH credentials and path to M2 folder
+ A migrated customer credentials which has login issue as you mentioned
I will help to check further and get back you then.
Regards,
Mall.
Hello,
I am unable to provide these due to legal and data protection reasons.
However, I am using a vanilla install of Magento 2.3.1 and your extension.
I can see your module adds the :0 which to be fair does seem to match the core code in terms of md5 encryption but it simply doesn’t work.
As per the link I shared, other people using your extension are reporting the same so I dont think it is something to do with my installation, it doesn’t make sense.
Hi there,
I can see your module adds the :0 which to be fair does seem to match the core code in terms of md5 encryption but it simply doesn’t work.
Yes, as explained in my reply #2, that is required for the migrated customer’s passwords in M2. And that process has been working fine for all our users so far.
I am unable to provide these due to legal and data protection reasons.
Due to the complicated factors associated with the migrated data, it is hard for us to provide you more details information about the issue you mentioned without having access to debug your instance.
What is the version of our migration tool in your instance? Anyway, please try to run the following SQL in your M2 database and then provide me the screenshot of the result after you run the SQL:
SELECT * FROM customer_entity_varchar WHERE attribute_id IN (SELECT attribute_id FROM eav_attribute WHERE attribute_code = 'password_hash');
Regards,
Mall.
Hello,
Thank you for your reply. Yes, unfortunetly we are bound by law on this under data protection..
The version of your module in use is: 3.2.0
That query returns an empty result. There is no data in that table from the attribute password_hash in customer_entity_varchar.
Like I said without the encoding code added to the end of the password it seems to work for some reason.
Please assist
Hi there,
I see your situation.
Like I said without the encoding code added to the end of the password it seems to work for some reason.
This issue is strange. Actually, it has been working for all other users using our migration tool. It seems your M2 has a third-party ext which affects the login function.
You can run the following CLI command to upgrade the migrated password hash to use the Magento2’s hash version 2 (sha256):
php -f bin/magento customer:hash:upgrade
For a specific reason that you want to clean the suffix ‘:0’ on password hash of migrated customer, you can apply the tweak code as follows to apply:
+ Open the PHP file at: pub/ub-tool/protected/controllers/Step6Controller.php
and find the code lines:
if ($table == 'customer_entity_varchar' AND $attributeCode1 == 'password_hash') {
$customer2->$attributeCode1 .= ":0"; // In Magento2: 0 is HASH_VERSION_MD5
}
and replace it with (in order to comment the code section that adds extra suffix):
/*if ($table == 'customer_entity_varchar' AND $attributeCode1 == 'password_hash') {
$customer2->$attributeCode1 .= ":0"; // In Magento2: 0 is HASH_VERSION_MD5
}*/
+ Once done, run the delta migration in step #6 with the ‘update’ mode:
php -f bin/ubdatamigration run --step=6 --mode=update
Regards,
Mall.
Hello,
Just for the record:
Actually, it has been working for all other users using our migration tool.
The ticket I shared demonstrates people using your extension and having the same problem.
Also, as per my previous comment:
However, I am using a vanilla install of Magento 2.3.1 and your extension.
So neither of these are correct, however with that aside….
I am aware of the SHA-256 password hash functionailty however the sheer volume of customer records (8.5 million) means that this native process wont complete. It eventually grinds to a halt and runs out of memory even with the highest spec AWS instance.
I will try your fix to passwords now and let you know if that resolves the issue.
I am however worried that this will eliminate our ability to hash the passwords to SHA-256 at a later date?
Hi there,
I am however worried that this will eliminate our ability to hash the passwords to SHA-256 at a later date?
There’s a high chance that there was a 3rd party extension (e.g which relates to log-in or authentication functionality) that affected the Magento core log in functionality. Thus, our workaround -- cleaning the suffix ‘:0’ on password hash of migrated customer -- was suggested for your specific circumstance only.
Actually, the suffix ‘:0’ was appended by our migration tool so that Magento 2 recognizes those credentials are migrated one. And with the suffix ‘:0’ in place, you can run the Magento2’s hash version 2 (sha256):
php -f bin/magento customer:hash:upgrade which is a core functionality of Magento 2. However, if you decide to clean such suffix ‘:0’, it might affect the SHA-256 harsh password processing later on.
You should consider to proceed (partial) data migration once again on a fresh Magento 2 instance to verify the log-in issue. For your information, with the current processing of our migration tool, all customers can log in in Magento 2 normally (with the same old credentials in Magento 1) after migration is done.
Regards,
Ubertheme team
Hello,
There’s a high chance that there was a 3rd party extension
Im not sure how many times I need to say it, for the 3rd time in this thread… It is a vanilla install Magento with no 3rd party extensions installed.
if you decide to clean such suffix ‘:0’, it might affect the SHA-256 harsh password processing later on.
In that case your tool isn’t fit for purpose.
I also commented out the code suggested and reran a delta but it hasn’t worked and all passwords just look the same and still don’t work:
/*if ($table == 'customer_entity_varchar' AND $attributeCode1 == 'password_hash') {
$customer2->$attributeCode1 .= ":0"; // In Magento2: 0 is HASH_VERSION_MD5
}*/
As you can probably tell, I’m loosing patience. You keep telling me its a 3rd party extension but I don’t have any. We simply need our customers to be able to login.
This migration started in July and we still don’t have a complete migration.
Please, please, please can you just help us find a path to resolution so that we can move forward? It is costing us money by the day.
Hi there,
We have been active to work closely with you so far. However it’s really hard for us to clarify the specific root cause of the issue when we have no access to review your instance.
Hundreds of our users have completed their data migration projects successfully so far without any login issue, so they could not be wrong with the login functionality.
There should be special factor(s) in your instance only that caused this issue.
Could you restart to follow our suggestion to run a partial migration once again to review the circumstance with your current M2 instance (this saves you time instead of running a full data migration)?
You should consider to proceed (partial) data migration once again on a fresh Magento 2 instance to verify the log-in issue.
Sincerely,
Ubertheme team
Hello,
Yes sure. This just seems to keep all the passwords the same as they are currently (with the :0 appended) but the passwords don’t work.
I would like to go back to one of your previous comments:
SELECT * FROM customer_entity_varchar WHERE attribute_id IN (SELECT attribute_id FROM eav_attribute WHERE attribute_code = 'password_hash');
This returns an empty result. None of the passwords (password_hash) seem to be migrated to the EAV in M2. They are however present in customer_entity.
Can I ask, is this expected behaviour? It seems like this could possibly be the cause of the issue here. What do you think?
I have triple checked and there are no 3rd party extensions. Just a base 2.3.1 installation
Hi there,
This returns an empty result. None of the passwords (password_hash) seem to be migrated to the EAV in M2. They are however present in customer_entity.
Yes, that is right. ‘password_hash’ was moved from EAV tables to store in the main table ‘customer_entity’. This was correct with the new M2’s database structure.
Can I ask, is this expected behaviour? It seems like this could possibly be the cause of the issue here. What do you think?
No, as explained the password_hash stored in the ‘customer_entity’ table was corrected.
I have triple checked and there are no 3rd party extensions. Just a base 2.3.1 installation
Have you tried to run data migration in a new M2 fresh instance with our migration tool for testing as suggested?
And did you download the M2 core source from this resource?
Regards,
Mall.
Have you tried to run data migration in a new M2 fresh instance with our migration tool for testing as suggested?
It takes 6 weeks to run due to the data volume so I can’t exactly run a quick test.
And did you download the M2 core source from this resource?
Yes of course, it’s the official release. 2.3.1.
Im now left in a position where I have spent literally 6 months getting the data across but the passwords don’t work.
It feels like the biggest waste of time ever.
Please can you provide me with some sort of path to resolution, please! other than just keep saying its at my end but I have explained and even provided a link of other customers of your explaining they see the same:
https://github.com/magento/magento2/issues/3758
Heres a quote from Magento themselves to clarify:
This issue belongs to migration tool, not magento 2 core
Your tool doesn’t work with Magento 2.3.1. Its just taken me 6 months and countless hours to establish that
Hi there,
We’re sorry for the late reply since we’ve just been back from our weekend.
even provided a link of other customers of your explaining they see the same:
https://github.com/magento/magento2/issues/3758
The link above referred to another context of the login issue. Such issue occurred when the password hash was stored in the wrong table customer_entity_varchar in Magento 2 which led to the issue (The correct table in M2 should be customer_entity).
In your circumstance, the password hash has been stored properly under the table customer_entity in your M2.
Since this issue appears to be specific for your case only (hundreds of our users completed their projects without any log in issue so far), we did suggest you proceed with a testing migration to transfer a small number of customers only (this does not take you much of time).
Regards,
Ubertheme team
Hello,
For me, i migrate Magento 1.9.4.4 and i change value :0 to :1 for hash version SHA256 and it’s work!
Good luck
if ($table == 'customer_entity_varchar' AND $attributeCode1 == 'password_hash') {
$customer2->$attributeCode1 .= ":1"; // In Magento2: 1 is HASH_VERSION_SHA256
}
Hi Magepulsar,
Actually, the login issue is more about a specific circumstance that differs from site to site.
Almost users using our migration tool so far did not encounter any issue with the login after the migration since all customer data was migrated automatically.
Anyway, thanks for sharing your workaround for others’ reference.
Regards,
Ubertheme team
Hi @Estrategiavirtual,
Please help to submit a separate ticket regarding your issue, we will work closely with you then.
PS. Since our team is off at the weekend, our apology for a certain delay in response during this time.
Regards,
Ubertheme team
Hi,
My name is Lawrence, I’m not a support here, just came across this ticket when I was experiencing the same problem but I figure out how to solve it eventually.
The problem I had:
Migrating around 4k customer accounts from Magento 1.7.3 to Magento 2.3.5-p1, we have a highly customized theme on Magento 2 and lots of 3rd extensions on it.
Once the customer account migration done, we can see all those accounts moved to Magento 2, but just can’t login to any customer account with the correct credential. The logins page keep saying the account is disabled or the password is invalid.
Solve problem:
I run the CLI which the support suggested in the earlier time:
php -f bin/magento customer:hash:upgrade
This actually helps to migrated M1 password hash to use sha256 on M2, we see the password hash been changed in SQL.
After this we still not able to sign in the customer account, then we noticed that the original customer accounts were assigned to the store view which is
Main Website-/Main Website Store -/ Default Store View
but our Magento 2 has a different store view which is
Main Website-/Main Website Store -/ English
Since the customer accounts still keep the old M1 store view record after moved to M2, that means the customer can’t logins because the old store view not existed on the M2. Once the customer accounts assigned to the correct store view on M2, problem solved.
If this help you solve the problem, plz let me know.
Btw, this UB migration tool is awesome, really help to migrate product data and customer data from M1 to M2, but there are some terms and settings not quite sure what they actually do on the migration. If the support team can provide more detailed documents on the knowledge base, that definitely help us getting know this tool.
Thank you.
Lawrence
Hi Lawrence,
Thanks for sharing your workaround.
but there are some terms and settings not quite sure what they actually do on the migration. If the support team can provide more detailed documents on the knowledge base, that definitely help us getting know this tool.
We’re not sure which settings and terms you referred to.
Regarding customer’s passwords, our module had a process that ensures customer’s passwords are validated & accepted in M2 after being migrated.
The wrong store view of the migrated customers as you mentioned does not occur with our module. Actually, our module automatically maps the changes in store views (if any) after migration.
Regards,
Ubertheme team
Hi team,
Thank you so much for getting back to me. I remember I have read the Migration Pro user guide before but can’t find it now, would you mind let me know where can I find the most updated user guide?
Regarding the customer account can’t access the storefront due to the wrong store view which retrieved from Magento1 but not matched the Magento2 actual store view name. We don’t know why it won’t map the changes in store views automatically liked you said, but we are able to solve this by running a SQL queue to change all the customer accounts at once to match the Magento2 store view name:
UPDATE `customer_entity` SET `website_id` = ‘M2 store view ID’ WHERE `customer_entity`.`website_id` = ‘M1 store view ID’;
Today we are experiencing another issue after the extension migrated the configurable products from Magento1 to Magento2, which is the Simple Products lost the <Color> attribute value after migrated to Magento2. I just ran the UB Data Migration Pro extension again to move the Simple Products and Configurable Products from M1 to M2 instance, the problem still remains.
Is there anything I might have missed or I need to tick some settings in order to move the Simple Products with <Color> attribute properly? Do you have an updated user guide I can check on with?
Thank you so much, appreciate all your help.
Best,
Lawrence
Hi Lawrence,
We wonder if you have another profile at Ubertheme. We could not keep track of the purchase associated with your profile.
If you are working on behalf of your client, please instruct your client to submit a ticket under the paid profile, we will follow up with you then.
We’re sorry for this additional step since our technical support requires an active subscription.
Thanks for your understanding.
Regards,
Ubertheme team
Hi,
Thank you for getting back to me quickly. Sure I am sending an email to my client to create a profile for us.
Much appreciate you and the support team helping out with our questions.
Keep you posted.
Best,
Lawrence
Hi Lawrence,
Yes, we will follow up on your case once your client submits a new ticket accordingly.
Regards,
Ubertheme team
Hi Davec,
This extension hands down does not work for migrating passwords.
Our module covers the migration of customers and related data automatically. And all changes between M1 vs. M2 have been taken into consideration in our compatibility releases so far.
Please submit a new ticket and provide us the credentials of your site instance, we will check and get back to you then.
- URL and admin credentials of your M2 instance
- SSH credentials of your M2 instance
- Let us know the path to your M2 root folder
Please make sure you mark the ticket private, then only you and our technical team can access it.
Regards,
Ubertheme team
If you say so. But as someone who has done a fresh migration on a fresh copy of 2.3.7-p2 MULTIPLE times (I’m talking like 5+) it “hands down does not work”
Everything else works perfectly, just the customer passwords. And when I used the steps I outlined above it worked first time. So…
Hi Davec,
We’re sorry for replying to you this late as our team has just been back from our weekend.
It’s hard to confirm the root cause of the issue now. If we had a chance to debug directly your instance, we can provide more details then.
But as someone who has done a fresh migration on a fresh copy of 2.3.7-p2 MULTIPLE times (I’m talking like 5+) it “hands down does not work”
There might be something wrong during the migration steps or there’s an issue with the configuration after you complete the migration.
Meanwhile, other users completed their migration projects without any issue with the customer log-in so far. The issue might be specific to your case though.
Regards,
Ubertheme team
