Every now and then, the Password Reset is not finding an email address even though it exists - so password reset not working

[mdmADA]

v4.6.1

Every now and then, one of ADA's users will report that the password reset isn't working - they don't receive the email. And it's not because the email is sent and somehow not received by the user, it's that the PasswordResetServiceBean can't find the email address in the first place despite the fact it exists.

For example, user1.abcdefg@gmail.com requests a password reset.

In server.log, the following log message is recorded:
[2019-01-09T16:12:23.807+1100] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.passwordreset.PasswordResetPage] [ti
d: _ThreadID=51 _ThreadName=jk-connector(4)] [timeMillis: 1547010743807] [levelValue: 800] [[
Couldn't find single account using user1.abcdefg@gmail.com]]

This message is logged by the PasswordResetServiceBean requestReset(email) method when it can't find the email address user1.abcdefg@gmail.com. (The other methods called don't log any messages so the message above is the only indicator of anything going wrong.)

When I check the authenticateduser table however, that email address IS there.

I looked at trailing spaces in the authenticateduser email field (none) and there are no spaces in the log message above (I tested it by adding a trailing space to my own email and it shows in the log message so if the user had entered spaces, it would show - ideally the code would trim all leading and trailing spaces...).

So I really don't know why the PasswordResetServiceBean can't find the email address when it does exist. And there isn't enough logging to know where the issue is.

Any ideas?

[pdurbin]

@mdmADA hi, I guess my first thought is that 4.6.1 is getting a little old at this point and you should know that in 4.9.3 we fixed some password reset problems by removing the duplication of email addresses across multiple tables as part of #4565.

[pdurbin]

@mdmADA to be extra clear, what I'm saying is that in 4.9.3 we dropped the "email" field from the "builtinuser" table:

https://github.com/IQSS/dataverse/blob/v4.9.3/scripts/database/upgrades/upgrade_v4.9.2_to_v4.9.3.sql#L2

So, please check your "builtinuser" table for user1.abcdefg@gmail.com or whatever.

[mdmADA]

Hi Phil - Thanks for the feedback. I was never quite clear as to why there was an 'authenticateduser' table AND a 'builtinuser' table that seemingly duplicates the former and never had time to investigate - now I know that the builtinuser table is for the the password reset functionality!

I did as you suggested and checked the builtin user table and that was indeed the problem - the emails in that table did not match the emails in the authenticateduser table.

As for 4.6.1 being 'old', it is 'extra old' and ADA is keenly aware of that fact but we are stuck here until we can get the Request Access functionality required for ADA's work processes integrated into the main codebase.

As an aside, a follow-on interesting design issue is that if a user enters an initial affiliation email (as they are required to do for ADA), and they move to another affiliation with a new email and their old original affiliation email is deactivated, if they forget their password they won't be able to reset it as the email will be sent to their old inactive email account. (If that makes sense). Perhaps this is addressed in more recent releases of Dataverse though.

ADA will be excited to be able to keep up with the upgrade cycle once we are able to do that.

Thanks!

[pdurbin]

@mdmADA sure. I'm glad you were able to get to the root of the problem and fix it for that user. Again, password reset should be less error prone after 4.9.3.

I saw emails flying around just today to coordinate next steps for #2043, the Request Access functionality you mentioned (and demo'ed to us a while back). It'll be great to have the feature and to have you back on "stock" Dataverse.

Do you want to close this issue? No pressure, but I'm not sure that it's actionable for anyone running 4.9.3 or higher.

[mdmADA]

I will close it as it seems to be no longer an issue in new versions. If others running older versions have the same problem at least they'll see this thread and see how to fix the problem.

Thanks!