While the original intent of the `secretsocket` script was to have `rbw`
run outside the `xactfetch` container, that is only useful during
development; both processes need to run in the container in Kubernetes.
When logging in to the Chase website with a fresh browser profile, or
otherwise without any cookies, the user will be required to "validate
the device" using a one-time code delivered via SMS. Previously, I
handled this by running the `xactfetch` script with a headed browser,
manually entering the verification code when the prompt came up. Then,
I would copy the `cookies.json` file, now containing a cookie indicating
the device had been verified, to the Kubernetes volume, where it would
be used by the production pod.
Now that `xactfetch` uses asyncio, it is possible for the Chase `login`
method to wait for one of multiple conditions: either login succeeds,
or SMS 2FA is required. In the case of the latter, we can get the
2FA code from the secret server and enter it into the form to complete
the login process.
The real magic here is how we're getting the 2FA code from the SMS
message. There are two components to this. First, I've installed [SMS
to URL Forwarder][0] on my phone. This app does what it says on the
tin: it relays SMS messages to an HTTP(S) server. I have configured it
to forward messages from the Chase SMS 2FA short code to an _ntfy_
topic. The second component is the `chase2fa` script, which is called
by the secret server. This script listens for notifications on the
_ntfy_ topic where the SMS messages are forwarded. When a message
arrives, it extracts the verification code using a simple regular
expression that identifies a several-digit number.
With all these pieces in place, the `xactfetch` script is no longer
thwarted by the SMS 2FA barrier!
[0]: https://github.com/bogkonstantin/android_income_sms_gateway_webhook
Dustin