Open Bug 2070265 Opened 20 hours ago Updated 20 hours ago

Audit other implicit `AuthIssues` transitions

Categories

(Application Services :: Fxa Client, defect)

defect

Tracking

(Not tracked)

People

(Reporter: bdk, Unassigned)

References

Details

(Whiteboard: [fxsync-])

For https://bugzilla.mozilla.org/show_bug.cgi?id=2060539, we changed it so that we don't transitions to AuthIssues when CheckAuthorization fails (we now only do that when it successfully returns active=false). Robin points out there are several other ways for this to happen:

  • This one where we initialize into the Connected state, but account.finish_initialize fails.
  • This one where we get the WebChannelPasswordChange event from the Connected state and handle_web_channel_password_change fails.
  • This one where we are in the AuthIssues state, get the BeginOAuthFlow event, and begin_oauth_flow fails.
  • This one where we are in the AuthIssues state, get the WebChannelPasswordChange event, and handle_web_channel_password_change fails.

We should investigate these and consider changing them to not move to AuthIssues.

My 2c:

This one where we initialize into the Connected state, but account.finish_initialize fails.

We can ignore this failure. All we're trying to do is notify the FxA server of our device capabilities, which probably haven't changed since the last time we did it.

This one where we get the WebChannelPasswordChange event from the Connected state and handle_web_channel_password_change fails.

We could keep the current behavior and move to auth issues since I think we know our refresh token is bad in this case. We could also not transition anywhere and instead store a flag that indicates we need to do the session token -> refresh token swap in this case. Is there plans to stop using the session token? If so, maybe we need to rework how this entire operation works.

  • This one where we are in the AuthIssues state, get the BeginOAuthFlow event, and begin_oauth_flow fails.
  • This one where we are in the AuthIssues state, get the WebChannelPasswordChange event, and handle_web_channel_password_change fails.

These seem okay to me, since we started in the AuthIssues state.

You need to log in before you can comment on or make changes to this bug.