no ref.
The default routing for the portal app is a signup page. When a site has
no recommendations, the result of triggering that page (by following a
link that goes there) is a prompt to sign up, or a notification that one
cannot sign up, if membership is disabled.
This patch adds a "No recommendations" message, which will be shown if a
user follows a recommendations link (#/portal/recommendations) on a site
without recommendations. While we shouldn't end up there very often,
it'll make a lot more sense when it does!
closes https://linear.app/ghost/issue/ENG-1672
- removed input on-blur validation because it can be triggered when clicking reset button giving a misleading error state
- added client-side validation for 6-digit code
- added validation when submitting the form
- added error reset when typing in the code field, including removal of button failure state, so it's clearer you're in a new submit state
no issue
- previously we determined any 403 response was an indication that we should switch to the 2fa input screen during sign-in
- added a custom error that explicitly looks for an error with our `2FA_TOKEN_REQUIRED` code so we don't have any confusion when a non-2fa 403 is received for any reason and to have the option of moving away from the 403 if needed without breaking the client
- test to ensure our error 2fa-required error detection works correctly
- extracted duplicate steps in the authentication tests into a helper function
- fixed authentication tests so they better represent our API output of `errors` being an array
closes https://linear.app/tryghost/issue/ENG-1652/
- returning `undefined` from a task is equivalent to failing
- switched to returning `true` when we get the 2fa required error so the button stays in the neutral/success state
- added `SUCCESS` and `FAILURE` consts to better reflect control flow when returning from tasks and ensured we always return a value
ref ENG-1629
Use separate protection for the 2 endpoints as one can resend an
email, and the other is used to login -- each presents its own
security challenges.
After migrations run, any sessions made with the labs flag turned off
will have the verified flag set. We also need new sessions made after
that to gain the verified flag, so that they aren't logged out at the
point that the labs flag is enabled (or removed).
ref ENG-1641
Using `getUserFromSession` requires the cookie header to be set, but
at this point we may still be constructing the session. Instead we can
get the user id from the session itself
More typical in TOTP setups for each token to last 1 minute, and to
allow some older tokens.
Also moved the options setting out of the generate scope in case
verify is called first (unlikely but possible).
closes https://linear.app/tryghost/issue/ENG-1617/
closes https://linear.app/tryghost/issue/ENG-1619/
- updated cookie authenticator's `authenticate` method to accept an `{identification, pasword, token}` object
- if `token` is provided, hit our `PUT /session/verify/` endpoint passing through the token instead of hitting the `POST /session/` endpoint
- added `signin/verify` route
- displays a 2fa code input field, including required attributes for macOS auto-fill from email/messages to work
- uses `session.authenticate({token})` when submitted
- updated signin routine to detect token-required state
- detects a `403` response with a `2FA_TOKEN_REQUIRED` code property when authenticating
- if detected transitions to the `signin/verify` route
