Error: Sorry, there is no match for that email address and/or password

[shags38]

v155f php7.1 treeoflifejewellery.com.au

Urgently need some help here please!

Customer created an account
was logged out when away from desk for a while (session timeout? normal)
Could not log back in >>>> Error: Sorry, there is no match for that email address and/or password

I changed the customers password and informed customer of new password
Customer again received this >>> Error: Sorry, there is no match for that email address and/or password

I created a personal account then logged out
I cannot log back in, same error >>> Error: Sorry, there is no match for that email address and/or password

I do not know if this has any bearing - I recently upgraded Image Handler to IH5 and there remains a green bar at the top of the admin page stating " Image Handler5 was successfully updated from vIH_VERSION to v5.1.1." ... this should disappear but has remained with every admin login.


any help greatly appreciated.
cheers,
Mike

[shags38]

edit ....
New login email address details are not showing up in the dropdown list on the login page among my 3 other 'personal' login details options, neither with the customer that alerted me to the issue (hers is blank), so it seems they are not being saved in the first place (for login) however the welcome email is sent and the customer(s) details show in admin/customers/ so something is being saved somewhere but not being recognized for login purposes.

Clearing cache and using a different browser makes no difference.

mike

[shags38]

edit ....

ALL newly established accounts show the customers in admin/customers but they do not show any of them anywhere in the database - not in customers, not in address_book.

Mike

[DrByte]

edit ....

ALL newly established accounts show the customers in admin/customers but they do not show any of them anywhere in the database - not in customers, not in address_book.

Mike

Impossible.
The admin/customers page pulls the data from the customers, customers_info, and address_book tables. So if they're in your admin, then they're in your database.
Perhaps you've disconnected your admin from your catalog by using a different database or database-prefix in your catalog configure.php vs your admin configure.php, so you're actually looking in the wrong tables?

[shags38]

Impossible.
The admin/customers page pulls the data from the customers, customers_info, and address_book tables. So if they're in your admin, then they're in your database.
Perhaps you've disconnected your admin from your catalog by using a different database or database-prefix in your catalog configure.php vs your admin configure.php, so you're actually looking in the wrong tables?

Spot on as usual DrByte - looked in wrong database. So the data is there in the database - I am not getting an error log so do not have something to check into - any ideas what may be causing the issue?

I am using One Page Checkout plugin, (configuration set to allow account registration), not sure if that can have any effect?

cheers, Mike

[DrByte]

Mike,
When did this new problem "start"? How does that intersect with code/server changes made recently?

Password login problems can be caused by issues with sessions, or by issues with code changed related to password handling/resets or adding master-password plugins.
In the normal course of operating a store none of those things are impacted ... unless of course you're manipulating plugins that do specifically affect that.
It's highly unusual for a login problem to just magically "start".

I don't think the One Page Checkout affects those areas, but you're the one who knows how your code has been altered from an original working fresh uncustomized Zen Cart install.

[shags38]

Mike,
When did this new problem "start"? How does that intersect with code/server changes made recently?

Password login problems can be caused by issues with sessions, or by issues with code changed related to password handling/resets or adding master-password plugins.
In the normal course of operating a store none of those things are impacted ... unless of course you're manipulating plugins that do specifically affect that.
It's highly unusual for a login problem to just magically "start".

I don't think the One Page Checkout affects those areas, but you're the one who knows how your code has been altered from an original working fresh uncustomized Zen Cart install.

Thanks for your reply DrByte - the word "sessions" reverberated in my head all night and "zenid". My robots.txt for this site had "Disallow: /zenid/" !!! needless to say removing that fixed the problem.

Yes dumb to the Nth degree. A few years ago (may have been v1.3.9) whilst going through GWMT I noticed a huge number of crawl errors the majority of which had "/zenid ................." suffix. This continued for some time and I figured this could not be helping the performance of the site so I put that disallow instruction in robots.txt and it solved the problem - not realizing of course it created a much bigger problem. (I didn't realize its purpose and I didn't ask in the forum before taking this dumb action)

So for at least a couple of years no customer's session id has been logged hence they have not been able to sign back in ... fortunately this has been a poor performing site for most of that period and only a couple of days ago did a customer try to log back in and advise me.

So in trying to fix an issue myself, without some knowledgeable help, I stuffed it up - so if I ask even more questions in forums then do not be surprised (ouch!) :)

I am grateful for your input.

thanks again,
Mike

[DrByte]

I should point out that "/zenid" is not standard Zen Cart URL format. It seems you've also got a URL-rewriter installed which is converting the session name into a URL parameter, and I mention this because sometimes URL-rewriting might be being done in a way that breaks things. I'd be more inclined to want my url-rewriter to leave the session name as a proper ?-notated parameter instead of converting it into slashes. That can make it easier for search engines to identify and ignore those as well (ie: webmaster tools lets you tell it what kinds of ? parameters to ignore in URLs). But that's way beyond the scope of this thread.

[shags38]

I should point out that "/zenid" is not standard Zen Cart URL format. It seems you've also got a URL-rewriter installed which is converting the session name into a URL parameter, and I mention this because sometimes URL-rewriting might be being done in a way that breaks things. I'd be more inclined to want my url-rewriter to leave the session name as a proper ?-notated parameter instead of converting it into slashes. That can make it easier for search engines to identify and ignore those as well (ie: webmaster tools lets you tell it what kinds of ? parameters to ignore in URLs). But that's way beyond the scope of this thread.

Yes, I'm using Ultimate URL's (USU) plugin - the "/zenid" may have been taken care of in more recent versions and when upgrading to a newer version I was remiss in removing the instruction which shouldn't have been there in the first place :) (I had that instruction in robots.txt in all of my sites in the same 'era' but subsequently removed it a while back - forgot this one I suppose - costly mistake on top of a costlier mistake).

Many thanks for your continued help.

cheers,
Mike

[barco57]

I created an account on the site, logout and logged right back in, then logged out and went away for ~45 minutes and then came back and logged right in without an issue.