wordpress-mobile / WordPress-iOS

WordPress for iOS - Official repository
http://ios.wordpress.org/
GNU General Public License v2.0
3.7k stars 1.12k forks source link

Web views not logged in when visiting Jetpack-connected self-hosted sites #15342

Open guarani opened 3 years ago

guarani commented 3 years ago

Expected behavior

When managing a Jetpack-connected self-hosted site, the app's functionalities which use web views should provide a logged in experience. These functionalities are:

Actual behavior

Navigating to any of these web views shows the page (except Reader, which seems to not work with this type of site), but does not automatically log the current app user into the web page shown in the web view

Steps to reproduce the behavior

Use any of the following on a Jetpack-connected self-hosted site:

Additional information

Tested on Tested on iPhone 11, iOS 14, WPiOS 16.1
designsimply commented 3 years ago

I noticed this comment from a related PR where the issue was found:

Jetpack-connected self-hosted The behavior is the same in 15.9 from what I can see, and consistent with the experience on the web. I'm not sure there is a lot we can do here as we can't rely on Jetpack's WordPress.com login module to be enabled, and we won't have credentials to authenticate with a password.

Source: https://github.com/wordpress-mobile/WordPress-iOS/pull/15309#issuecomment-730490286

@aerych as a way to make this issue actionable in the near term, would it be possible to at least detect whether Jetpack's WordPress.com login module is enabled and show an explanation if it isn't? I'll also welcome any other potential solutions if you happen to think of any?

aerych commented 3 years ago

would it be possible to at least detect whether Jetpack's WordPress.com login module is enabled and show an explanation

It should be possible with a little work. The REST API's /sites/site endpoint returns jetpack_modules, a list of names of the enabled Jetpack modules. If sso is not in the list we could prompt the user.

aerych commented 3 years ago

Actually it might be easier than I thought. Looks like block options returns active_modules which is the same list as jetpack_modules. This should already be stored in the Blog model and available to check via a call to [Blog jetpackActiveModule:@"sso"]; or something along those lines.