Says the other device really did scan the code this one showed.
The one thing a person still has to do in a flow with no string to
compare, and it is the same act confirmVerification asks for:
that was my other phone, not somebody's screenshot. Ask before calling
this. A product that confirms on its own has verified nothing, however
well-formed its arguments were, because whether a person recognised the
device that scanned is not observable from inside this process.
Rejects with 'unknown_flow' for an identifier naming no flow this process
is taking part in, and with 'wrong_stage' when nobody has scanned this
device's code yet, and also when the flow is over. Those two want opposite
things done -- wait, versus start again -- and this call still cannot tell
them apart on its own. getVerificationStage now can, which it
could not when this rejection was first written: 'started' is nobody has
scanned yet, 'code-scanned' is the one stage this call succeeds at, and
'done' or 'cancelled' is over. Read it before calling this rather than
after, and the rejection stops being reachable for anything but a race.
Skipping it does not fail loudly, but it does fail. A flow nobody
confirms sits open until the protocol's own ten-minute timeout retires it.
And calling it does not always end the flow, through no fault of yours.
Some clients declare themselves finished the instant they accept a scan,
before you have been asked anything. That is a deviation from the
specification on their side, which puts that message after the
confirmation you are being asked for; the message that would have
completed this flow was spent then and no second one is coming. This call
still succeeds, the stage moves to 'confirmed', and it stays there. See
getVerificationCode for the measurement behind that. Give the
person a way out of that screen and call cancelVerification when
they take it, which is the only thing that frees them to verify that
contact again.
Says the other device really did scan the code this one showed.
The one thing a person still has to do in a flow with no string to compare, and it is the same act confirmVerification asks for: that was my other phone, not somebody's screenshot. Ask before calling this. A product that confirms on its own has verified nothing, however well-formed its arguments were, because whether a person recognised the device that scanned is not observable from inside this process.
Rejects with
'unknown_flow'for an identifier naming no flow this process is taking part in, and with'wrong_stage'when nobody has scanned this device's code yet, and also when the flow is over. Those two want opposite things done -- wait, versus start again -- and this call still cannot tell them apart on its own. getVerificationStage now can, which it could not when this rejection was first written:'started'is nobody has scanned yet,'code-scanned'is the one stage this call succeeds at, and'done'or'cancelled'is over. Read it before calling this rather than after, and the rejection stops being reachable for anything but a race.Skipping it does not fail loudly, but it does fail. A flow nobody confirms sits open until the protocol's own ten-minute timeout retires it.
And calling it does not always end the flow, through no fault of yours. Some clients declare themselves finished the instant they accept a scan, before you have been asked anything. That is a deviation from the specification on their side, which puts that message after the confirmation you are being asked for; the message that would have completed this flow was spent then and no second one is coming. This call still succeeds, the stage moves to
'confirmed', and it stays there. See getVerificationCode for the measurement behind that. Give the person a way out of that screen and call cancelVerification when they take it, which is the only thing that frees them to verify that contact again.