Audit other implicit `AuthIssues` transitions
Categories
(Application Services :: Fxa Client, 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
Connectedstate, butaccount.finish_initializefails. - This one where we get the
WebChannelPasswordChangeevent from theConnectedstate andhandle_web_channel_password_changefails. - This one where we are in the
AuthIssuesstate, get theBeginOAuthFlowevent, andbegin_oauth_flowfails. - This one where we are in the
AuthIssuesstate, get theWebChannelPasswordChangeevent, andhandle_web_channel_password_changefails.
We should investigate these and consider changing them to not move to AuthIssues.
Updated•20 hours ago
|
| Reporter | ||
Comment 1•20 hours ago
|
||
My 2c:
This one where we initialize into the
Connectedstate, butaccount.finish_initializefails.
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
WebChannelPasswordChangeevent from theConnectedstate andhandle_web_channel_password_changefails.
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.
These seem okay to me, since we started in the AuthIssues state.
Description
•