-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Login: Replace endpoint that fetches site info when using a site address to login #12940
Login: Replace endpoint that fetches site info when using a site address to login #12940
Conversation
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
Generated by 🚫 dangerJS |
You can test the changes on this Pull Request by downloading the APK here. |
d069324
to
2debdef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test scenarios work as expected! I'm not super familiar with the login codebase, but nothing particularly stands out to me 👍
Fixes #12832
When logging in using a site address, we used to make a call to
/sites/$site
to fetch more info about the site and to determine if we should treat it as a WordPress.com site or a self-hosted one.That endpoint did not work well with private sites, which would cause issues for users that had custom domains and 2FA enabled (you can read more about it in the linked issue or in this internal ref: pbArwn-16v-p2).
This PR replaces the usage of that endpoint with
/connect/site-info
, which allows us to better handle those situations. This endpoint was already being implemented in the LoginFlow library, but was only used by the Woo app. I tried to reuse some of that code, while also making sure to keep the existing behavior regarding how to treat different site types (WordPress.com, Jetpack and self-hosted).To test
You can test the following scenarios by creating sites with jurassic.ninja or by using a pre-configured test site.
Main Scenario
Private WordPress.com site with custom domain and 2FA enabled
Secondary Scenarios
WordPress.com, Self-Hosted or Jetpack site
Note: While working on this PR, it was noted that Atomic and Jetpack sites are being treated as Self-Hosted sites as opposed to WP.com sites, which is the expected behavior. This will be addressed in a follow-up PR.
HTTP Auth
Self-Signed SSL
PR submission checklist:
RELEASE-NOTES.txt
if necessary.