Page MenuHomePhabricator

When issuing a "no-op" MFA token because no MFA is configured, don't give the timeline story a badge
ClosedPublic

Authored by epriestley on Jan 30 2020, 3:33 PM.
Tags
None
Referenced Files
F14098286: D20958.id49933.diff
Tue, Nov 26, 8:47 AM
F14096807: D20958.diff
Tue, Nov 26, 5:23 AM
Unknown Object (File)
Mon, Nov 25, 12:43 AM
Unknown Object (File)
Fri, Nov 22, 1:06 PM
Unknown Object (File)
Thu, Nov 21, 12:33 PM
Unknown Object (File)
Wed, Nov 20, 7:20 PM
Unknown Object (File)
Sun, Nov 17, 5:20 AM
Unknown Object (File)
Tue, Nov 12, 6:43 AM
Subscribers
None

Details

Summary

Fixes T13475. Sometimes, we issue a "no op" / "default permit" / "unchallenged" MFA token, when a user with no MFA configured does something which is configured to attempt (but not strictly require) MFA.

An example of this kind of action is changing a username: usernames may be changed even if MFA is not set up.

(Some other operations, notably "Sign With MFA", strictly require that MFA actually be set up.)

When a user with no MFA configured takes a "try MFA" action, we see that they have no factors configured and issue a token so they can continue. This is correct. However, this token causes the assocaited timeline story to get an MFA badge.

This badge is incorrect or at least wildly misleading, since the technical assertion it currently makes ("the user answered any configured MFA challenge to do this, if one exists") isn't explained properly and isn't useful anyway.

Instead, only badge the story if the user actually has MFA and actually responded to some kind of MFA challege. The badge now asserts "this user responded to an MFA challenge", which is expected/desired.

Test Plan
  • As a user with no MFA, renamed a user. Before patch: badged story. After patch: no badge.
  • As a user with MFA, renamed a user. Got badged stories in both cases.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision was not accepted when it landed; it landed in state Needs Review.Jan 30 2020, 3:34 PM
epriestley requested review of this revision.
This revision was automatically updated to reflect the committed changes.