HTTP 500 errors during MFA verification result in an endless spinner

[madmatt]

If you trigger an HTTP 500 during the MFA verification (e.g. the HTTP POST to /Security/login/default/mfa/verify/totp?SecurityID=<redacted>) and the response is an HTTP 500 (generally because you're in live mode and there's an exception thrown), the site never refreshes and you just get stuck looking at the spinner forever.

Acceptance Criteria

• Existing error UI patterns are utilised where possible (Consult with the PUX team on what would make sense)
• All error responses are handled correctly (including 429s)

Resolving the root causes of these error responses is out of scope for this issue.

PRs

• [x] https://github.com/silverstripe/silverstripe-mfa/pull/401 (Fix 500 + 429)

Note: not fixing this for SS3 as this is a non-critical issue

[Cheddam]

Definitely belongs here @madmatt, thanks for raising this 👍

[Cheddam]

Dug into this today, and though I don't have a PR ready for review, here are some notes:

• We desperately need to improve CMS's awareness and handling of content types, and document recommended practices for building flexible requests / responses. As an example, the RateLimitMiddleware has zero awareness of what content types are specified in the Accept header of the request, and so responds with HTML every time. There are a lot of areas of the CMS where we get bizarro, unhelpful errors because we blindly try to parse responses as JSON.
• My WIP uses the Content-Type header in the response to work out whether it's valid JSON, and if not, wraps the body in an object in order to allow outputting the error message inline. I looked into making this apply across the whole module via the api helper method, but applying rudimentary middleware to fetch() is actually pretty tough going. There'll be other places in the codebase I need to patch this functionality in, but the WIP has been tested to make 429s successfully return to the code entry UI with a 'Rate limited' error.
• Simply displaying the contents of the response when it's plain text or HTML isn't necessarily going to result in user-friendly output, so I'll need to chat to @sachajudd / @clarkepaul about how best to tackle this. Might need to settle on a generic set of error messages based on the HTTP status code.