Can't access my account after resetting my password

[ckarlof]

I have a prod account c<last name>@gmail.com that after I reset the password, I can't log in with the password I chose. I've forgotten the original password. I can reproduce this every time. @monicachew has seen a similar issue.

[vladikoff]

I have a prod account

Assuming https://accounts.firefox.com/ I was not able to reproduce via https://accounts.firefox.com/reset_password with my @gmail.com Nightly 2014-02-06

[ckarlof]

I was not able to reproduce via https://accounts.firefox.com/reset_password with my @gmail.com

Yeah, it's not generally reproducible.

[ckarlof]

status: @dannycoates has my prod DB entry and is debugging.

[rfk]

Possibly another instance of https://bugzilla.mozilla.org/show_bug.cgi?id=965917 - I will forward the record from that bug to @dannycoates to see if any similarities stand out.

[dannycoates]

luckily using @ckarlof's account record from production I'm able to reproduce this locally with a test script

[dannycoates]

I've found the issue on local, unfortunately I doubt it is the same problem as production. Locally the default verifierVersion is set to 0. @ckarlof's account was set to use 1. It's ok to have a mix of versions, but there's a bug in the code that uses the server configured verifier version for the new password (to allow upgrading version on reset) but doesn't update the account to the new version.

If the production servers used to be configured as 1, but are now configured as 0 (after these accounts were created) then resetting the account will lock you out.

@gene1wood what is verifierVersion of the config set to in production at the moment? If unset it defaults to 1.

[gene1wood]

The value is unset and therefore defaulting to 1 : https://github.com/mozilla-services/puppet-config/blob/master/fxa/modules/fxa/templates/data/fxa-auth-server/config/default.json.erb

[monicachew]

If you need another account to debug, mine is mmchew@gmail.

[dannycoates]

Thanks, all. It turns out I also have an "old" account in prod with this issue. I think I'm getting closer to solving it.

[dannycoates]

Ok, there is indeed a problem with verifierVersion but I'm still investigating the "how things got the way they are" part. I suspect there are other factors in play.

[dannycoates]

I've confirmed my earlier comment is the issue, and I've got a fix on the way.

Somehow prod thinks it's verifierVersion = 0 which is also a problem.

@gene1wood the template you linked certainly doesn't set it; are there any other config files loaded in the environment variable CONFIG_FILES or a config/prod.json file? Alternatively, if NODE_ENV is not 'prod', that could be an issue.

[gene1wood]

Here's the CONFIG_FILES variable : https://github.com/mozilla-services/puppet-config/blob/master/fxa/modules/fxa/manifests/auth_server.pp#L94

We don't create a config/prod.json and it looks like the app doesn't come with one : https://github.com/mozilla/fxa-auth-server/tree/master/config

NODE_ENV, the environment variable, is not set : https://github.com/mozilla-services/puppet-config/blob/master/fxa/modules/fxa/manifests/auth_server.pp#L92 and it's not set in the config file : https://github.com/mozilla-services/puppet-config/blob/master/fxa/modules/fxa/templates/data/fxa-auth-server/config/default.json.erb

It appears that the default value is dev https://github.com/mozilla/fxa-auth-server/blob/master/config/config.js#L11

So is that the cause?

[dannycoates]

@gene1wood where does @env come from?

here: https://github.com/mozilla-services/puppet-config/blob/master/fxa/modules/fxa/templates/data/fxa-auth-server/config/default.json.erb#L41

[dannycoates]

code-wise this is fixed

[gene1wood]

@dannycoates @env comes from the Env tag applied to the ec2 instance.

https://github.com/mozilla-services/puppet-config/blob/master/common/puppet/bin/enc#L30

That value in turn comes from what's entered when the stack is created

https://github.com/mozilla-services/svcops/blob/master/cloudformations/firefox-accounts/fxa-auth-server.json#L7

[dannycoates]

@gene1wood I see both $env (dollar sign) and @env (at sign) in that file. Is one of them a typo? It could explain how the code may be set to dev mode because if it generates "env":"" the code will default to "dev". I'm reluctant to send a PR because I haven't built a stack yet to test it.

[ckarlof]

gotofail?

I was always concerned @gene1wood might be an NSA plant...

[gene1wood]

My handler will be very disappointed that my cover was blown by an ERB typo. Well that was a bunch of tax payer money down the drain.

Since my government gig is now toast, I'll go fix this bug in hopes that it ingratiates me with my target, maybe they'll keep me on.

[edwindotcom]

I think danny was alluding to this, but we should prob default everything to 'prod' or most secure, as we get closer to release.

[ckarlof]

It could explain how the code may be set to dev mode because if it generates "env":"" the code will default to "dev".

As Edwin mentions, an empty env should default to prod mode. We should require that dev environments be explicitly configured.

wrt to the bug @gene1wood fixed, the $ was the typo which affects the redirectDomain property, which I think we probably aren't relying on anymore.