Closed Bug 1262272 Opened 6 years ago Closed 6 years ago

Use push so clients discard their sync token and/or certificate on password change


(Firefox :: Firefox Accounts, defect, P2)




Firefox 48
Tracking Status
firefox48 --- fixed


(Reporter: markh, Assigned: lina)




(1 file)

When a user changes their password on device 1 while device 2 is running, device 2 needs to wait for the token to expire before it notices a new password is required - which may take up to 6 hours. We should try and use push so that device 2 sees the change sooner.

It might even be possible to reuse the existing FXA_PUSH_SCOPE_ACCOUNT_UPDATE message - the one used when a user verifies. FxA could just take this as meaning "the account status changed in some way" and discard the token and or certificate, which would then cause us to get an auth-error fetching a new one, and quickly enter the "needs reauth" state.

This is a desktop bug, but CC rnewman and nalexander to see if they want an equivalent for iOS/Android
Flags: firefox-backlog+
Going to put a proof of concept together for Desktop during our Sync work week.
Assignee: nobody → kcambridge
Priority: -- → P2
If we reused FXA_PUSH_SCOPE_ACCOUNT_UPDATE, I think this is all we'd need to do on Desktop. If the user changed her password, verification will fail, which will cause us to discard the session token and prompt her to reauthenticate.

I agree that reusing the endpoint (or adding another data-free endpoint for password change) is best, as this doesn't require Android and iOS to natively support push message decryption.
Attachment #8740727 - Flags: review?(markh) → review+
Comment on attachment 8740727 [details]
MozReview Request: Bug 1262272 - Unconditionally poll the verification status for FxA push messages. r?markh


::: services/fxaccounts/FxAccounts.jsm:680
(Diff revision 1)
>        }
> -      if (!this.isUserEmailVerified(data)) {
> +      // Always check the verification status, even if the local state indicates
> +      // we're already verified. If the user changed their password, the check
> +      // will fail, and we'll enter the reauth state.
> +      if (this.isUserEmailVerified(data)) {

I don't think the if() continues to have value and it's cognative overhead - just use an unconditional log.trace() and be done IMO.
Duplicate of this bug: 1206325
Kit, you mentioned we need additional server support for this to finally work - can you please make sure you link to either the PR or bug to make this happen?
Flags: needinfo?(kcambridge)
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Appropriately, it's PR #1234. ;-)
Flags: needinfo?(kcambridge)
Product: Core → Firefox
Target Milestone: mozilla48 → Firefox 48
You need to log in before you can comment on or make changes to this bug.