search

mozilla / sumo

Project management board for SUMO and Community properties.
Mozilla Public License 2.0
14 stars 5 forks source link

Investigate why we don't get/store SETs for certain Firefox Accounts #469

Open LeoMcA opened 4 years ago

LeoMcA commented 4 years ago

Continuing from https://github.com/mozilla/sumo-project/issues/452#issuecomment-639443230:

We're haven't stored any any FxA notifications for the mozillatest1234@yahoo.com account... either FxA is sending them to us, and for some reason we're failing to store them, or FxA doesn't send notifications for this account (maybe because it has "test" in the name?).

LeoMcA commented 4 years ago

This is what I'm pretty confident happened in this case:

  1. The account was created on FxA and on SUMO
  2. The account was deleted on FxA, but we didn't have notifications set up yet, so wasn't deleted on SUMO
  3. The account was then created again on FxA, with the same email address, but was given a different user id
  4. That account could still be used to log into the SUMO account, because when we can't match on user id we fall back to the default mozilla-django-oidc behaviour of matching on email. However, we don't update the user id to the new one
  5. Notifications that are send by FxA are sent with the new user id, which we haven't associated with the SUMO account, so we can't associate those notifications with their SUMO account

The "ignored" notifications (ones we can't associate with a user) on dev all belong to the same FxA user id, lending credibility to this idea, and I confirmed locally that deleting and recreating a FxA account doesn't update the user id we store.

The fix should probably be twofold:

  1. Update FxA user id whenever we fallback to email for login, to ensure future notifications can be associated correctly with the account.
  2. When processing jobs, recheck to see if a user's FxA user id and the user id in the notification match. If not, error and don't process the job. This is to prevent a situation like the following:
    1. User deletes FxA account
    2. User recreates FxA account and logs back into SUMO before notification is sent/processed
    3. User's account then, seemingly randomly, gets deleted on SUMO when the notification is processed