You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When they log in via web view, a newly signed-up user who hasn't set a password(*) yet will have the only option of receiving a login link in their email. However, the login flow in the web view does not move on after the user taps the login link to authorize access.
(*) On a desktop browser, the "Get Started" on https://wordpress.com workflow allows you to create accounts without setting a password.
Potential fixes
There are two options to fix the issue:
Option 1. Handle the redirect URL in the iOS app
When the user taps the login link from their email, they'll open Safari to authorize the mobile app's access to their account. After that, the webpage should redirect the user to the app, which takes over the login (via token in the redirect URI).
However, if the user taps the login link from another device (computer, phone, tablet, whatever), the app will still be stuck at the "Check your email for the login link" Calypso webpage, and the user still can't log in to the app even though they have done what WP.com tells them to do. That's why I think the option 2 below might be a better solution.
Option 2. Calyspo polls the authorization result for the login link
When the user logs in from the app via web view and arrives at the "Check your email for the login link" webpage, they should be able to open the login link from any device.
The login link can present the usual Deny/Authorize access webpage, and shows a message "Continue from the mobile app" after the user deny/authorize the access.
Meanwhile, the "Check your email for the login link" webpage in the app should poll the authorization result of the login link and automatically take the user to the next step based on the result.
There are many alternatives to polling, such as showing a code in the login link and asking the user to type it into the app. Both are standard practices used in many other apps.
The text was updated successfully, but these errors were encountered:
Issue
When they log in via web view, a newly signed-up user who hasn't set a password(*) yet will have the only option of receiving a login link in their email. However, the login flow in the web view does not move on after the user taps the login link to authorize access.
(*) On a desktop browser, the "Get Started" on https://wordpress.com workflow allows you to create accounts without setting a password.
Potential fixes
There are two options to fix the issue:
Option 1. Handle the redirect URL in the iOS app
When the user taps the login link from their email, they'll open Safari to authorize the mobile app's access to their account. After that, the webpage should redirect the user to the app, which takes over the login (via
token
in the redirect URI).However, if the user taps the login link from another device (computer, phone, tablet, whatever), the app will still be stuck at the "Check your email for the login link" Calypso webpage, and the user still can't log in to the app even though they have done what WP.com tells them to do. That's why I think the option 2 below might be a better solution.
Option 2. Calyspo polls the authorization result for the login link
When the user logs in from the app via web view and arrives at the "Check your email for the login link" webpage, they should be able to open the login link from any device.
The login link can present the usual Deny/Authorize access webpage, and shows a message "Continue from the mobile app" after the user deny/authorize the access.
Meanwhile, the "Check your email for the login link" webpage in the app should poll the authorization result of the login link and automatically take the user to the next step based on the result.
There are many alternatives to polling, such as showing a code in the login link and asking the user to type it into the app. Both are standard practices used in many other apps.
The text was updated successfully, but these errors were encountered: