Customizer: Auto-sign into system WebView when launching Customize WebView from system browser

[tonyr59h]

Context: Refer to #4934 and #5071 for discussion.

Expected behavior

Since the user is signed in on the app already we should be able to authenticate automatically when launching a WebView, but the user is prompted for their credentials when the system WebView is launched.

Steps to reproduce the behavior

• Sign in and head to Themes page
• Select Customize
• WebView is shown on sign in page

Tested on Pixel (API 24), Genymotion (API 16/23)

[rachelmcr]

A couple users have left negative app reviews, remarking on the recent change that opens the customizer in the browser. Authenticating that view for the user might help this feel less disruptive.

[DanReyLop]

In my case, I was prompted to login into wordpress.com in the default browser, but I couldn't actually login. I was prompted for my 2FA code correctly, but after I entered it, the login form was displayed again. This may not be the app's fault but it gives a really poor user experience.

[formosattic]

I was able to login to wordpress.com in the default browser but the Customizer took so long trying to load that I closed it (progress bar was moving but nothing displayed), went back to the app to launch the Customizer again, and it loaded fine this time around.

Although, I also found out that I could more easily access the Customizer from within the app, which is convenient but the path to it much less intuitive (considering there's already the more obvious Customize button on the Themes screen):

• Themes > Details > Customize
  or
• Themes > 'Details' or 'Support' > W > Customize

Tested on S7 Edge, 7.4-rc-2.

[rachelmcr]

This came up again in testing feedback (internal ref: pxLjZ-50u-p2).

I'm not sure how much work it would be to implement this, so I've added it to the groundskeeping project — if it can't be done during groundskeeping I'd like to at least work out how much effort it would take.

[SiobhyB]

Noting a recent three star review:

It is absolutely annoying how I cannot customize my site on the app. Why does it need to redirect to the browser? The app constantly hangs. It is not as efficient as when you use it on PC

[SiobhyB]

Feedback from a three star review:

...will rate 5 if you remove the accessing theme customizer from browser. Previous update was good where everything was managing only from App.

[designsimply]

Webviews often have problems with interactions such as sharing or likes or comments. Would the Customizer be usable from within a webview?

Note: I moved this issue to the Prioritized Android list in Groundskeeping because of the negative related app-store reviews.

[rachelmcr]

@designsimply I think for clarity we should retain the original title on this issue ("Auto-sign into system WebView when launching Customize WebView from system browser").

The changes from #4934 and #5071 were specifically to launch the Customizer in the system browser, not an app webview, because there were problems with the Customizer's features not all working in the app webview. This is a followup issue to try auto-authenticating the user in the system browser, to make that flow from the app to the browser smoother (so users don't have to log in again).

[malinajirka]

I have been thinking about a solution for this task. I haven't came up with a secure simple solution.
AFAIK we can't send POST parameters through intent. This means we'd need to send the credentials (or token) as a query parameter in the URL itself. However, whatever we send to the external browser might be accessible later - eg. in the browser's history. It really depends on the browser app - it can do whatever it wants with the data. So the security implications of this approach make it unusable IMHO. Moreover, even if the browser app would be nice and wouldn't store the URL into the history, users might be pretty surprised if they used only the app and they ended up being logged into the system browser.

I think we have the following options

1. Don't change anything. If the user is logged in the system browser, the log in state is preserved and they don't need to login again when they access the customizer from the app.

2. Switch back to using the internal browser (webview/custom tabs) and look into our options on how to enable choosing a file from the local storage.

3. Implement an endpoint similar to the one we use for magic link login which would provide us with a short-living (eg. 3 minutes) one-time SSO token. The flow would look similar to this

• get SSO token from the endpoint (from within the app)
• send browser/view intent with "public-api.wordpress.com/verify-sso?sso-token=XYZ&redirect=https://wordpress.com/customize/[BLOG_URL]
• an external browser loads the URL
• the server would verify the SSO token and redirected the browser to the customizer

If the user opened the system browser app in the following 3 minutes they'd still be surprised to see they are logged in, but the security risks would be definitely way lower and probably acceptable. We could even invalidate the token from the app when the user leaves the customizer.

All in all, I can't think of a simple solution. Solution number 3 is definitely more suitable for team-projects than a groundskeeping task. Solution number 2 might be worth investigating unless somebody already explored this option.

[rachelmcr]

At this point I'd recommend the first option:

Don't change anything. If the user is logged in the system browser, the log in state is preserved and they don't need to login again when they access the customizer from the app.

Given that there isn't a simple solution here and we're already working on a Gutenberg site editing experience, it makes sense to keep the project focus on Gutenberg and let the current customizer continue as it is. Especially since this isn't a blocker to using the customizer (it just requires logging in to the same account in the browser that you're logged into in the app).

[malinajirka]

I completely agree it makes sense to keep it as it is -> Closing as won't fix.