Users locked out, can't reset password 'Expired link message'

Bug reports
1

Hi,

Some of our users are getting 'expired link' messages, either after

  1. resetting password from admin
  2. user doing forgot my password
  3. adding new user

image
image775×501 42.4 KB

The thing making it tough to troubleshoot is that one of our admins WAS able to add themselves as a user with a spare email. (I tried to add an extra email - I was not able to log in with it, I got the same 'expired link' message.)

Great if someone has bumped into this and has any ideas, we are in a not good situation on this.

We recently upgraded to 42.2 - it may be that it started AFTER this - it has been a while but we don't need new users or resets on that installation very often.

Another confounding element, is that we have a separate metabase installation, same version, and as far as we know everything else the same, but we are able to add users and password reset users on this just fine.

One final clue - but not sure it matters, on the metabase installation with the problem this section says https issue, not sure why, pretty sure I did not touch that.

image
image1306×526 44.3 KB

Where the 'working' installation shows:

image
image724×285 15.4 KB

Thank you in advance for your time!

Jaz

{
"browser-info": {
"language": "en-US",
"platform": "Win32",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36",
"vendor": "Google Inc."
},
"system-info": {
"file.encoding": "UTF-8",
"java.runtime.name": "OpenJDK Runtime Environment",
"java.runtime.version": "11.0.14.1+1",
"java.vendor": "Eclipse Adoptium",
"java.vendor.url": "https://adoptium.net/",
"java.version": "11.0.14.1",
"java.vm.name": "OpenJDK 64-Bit Server VM",
"java.vm.version": "11.0.14.1+1",
"os.name": "Linux",
"os.version": "4.14.262-135.489.amzn1.x86_64",
"user.language": "en",
"user.timezone": "GMT"
},
"metabase-info": {
"databases": [
"mysql",
"redshift",
"googleanalytics",
"snowflake"
],
"hosting-env": "unknown",
"application-database": "mysql",
"application-database-details": {
"database": {
"name": "MySQL",
"version": "8.0.25"
},
"jdbc-driver": {
"name": "MariaDB Connector/J",
"version": "2.6.2"
}
},
"run-mode": "prod",
"version": {
"date": "2022-02-28",
"tag": "v0.42.2",
"branch": "release-x.42.x",
"hash": "d6ff494"
},
"settings": {
"report-timezone": null
}
}
}

2

Why is report-timezone null? Could that be the problem?

1 Like
3

@AndrewMBaines It's null, when you have set Report Timezone to "Database default", which basically means it will get timezone from JVM.

@jazz78 The password reset is valid for 48 hours. Something makes me think that you have a timezone or system clock issue somewhere. Check the time of servers running Metabase and MySQL, and make sure that they have updated OS tz_data.
Since the problem only occurs on a single instance, then the problem is specific to that instance.

As for the Site URL problem - that's likely caused by bad reverse-proxy headers. Again, since it only happens on a single instance, then the problem is with the setup of that instance.

1 Like
4

Thanks @AndrewMBaines thanks and hi again @flamber great work on recent releases, we love it :rocket: , and we finally moved off h2 as you had recommended.:+1:

@flamber we will try this - it is plausible, the four users we are testing the issue with are are all in substantially different time zones - although the one person who did not get the 'expired' message is in between two who could not, so that does not fit with the theory, but maybe there is some other explanation for that.

Will advise thanks.

5

@flamber @AndrewMBaines

It is resolved, it was an error on the site URL setup . Either when we upgraded, or when we moved off H2 this particular installation URL got messed up. It also cannot be ruled out that one of the admins on this site edited the URL by hand, I don't believe I did or any of the other admins did, but we cannot rule it out.

The '1 ' person who had success - was a miscommunication, that person was testing another installation, in fact no-one could reset passwords or users on this particular installation.

Thanks for taking a look at this, and sincere apologies for using up your valuable time here.

Regards
jaz

1 Like
6

@jazz78 Thank you for taking your time to write the "solution".

1 Like