Skip to content
This repository was archived by the owner on Feb 5, 2025. It is now read-only.

Conversation

@yaelirub
Copy link
Contributor

Self hosted sites that have jet pack return with a successful response from the fetch site so we don't show the "logout" prompt for those sites.

Before:
self_hosted_jetpack1

After:
self_hosted_jetpack

Self hosted sites that have jet pack return with a successful response from the fetch site so we don't show the "logout" prompt for those sites.
@yaelirub yaelirub added the bug Something isn't working label May 24, 2019
@yaelirub yaelirub requested review from aerych and mindgraffiti May 24, 2019 02:00
@yaelirub
Copy link
Contributor Author

yaelirub commented May 24, 2019

@aerych , @mindgraffiti , I took a shoot a this as more users are experiencing difficulties logging in:

Can you think of any issues with allowing the flow to continue with this added condition?

@yaelirub
Copy link
Contributor Author

@aerych , @mindgraffiti would you mind taking a look?

@aerych
Copy link
Contributor

aerych commented May 28, 2019

Sorry Yael! This one got lost over the holiday shuffle. Taking a look.

Copy link
Contributor

@aerych aerych left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested and confirmed the bug. I was trying to understand how it was happening when I noticed some other odd things. I'm not 💯 sure this is the best patch. More details in my comment.

let successBlock: (WordPressComSiteInfo) -> Void = { [weak self] siteInfo in
self?.loginFields.meta.siteInfo = siteInfo
if WordPressAuthenticator.shared.delegate?.allowWPComLogin == false {
if WordPressAuthenticator.shared.delegate?.allowWPComLogin == false && !siteInfo.hasJetpack {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So... there are a few things going on in fetchSiteInfo and its associated code paths that seem off to me. For example, the else block in the conditional following the success block is never executed. I suspect there might be more work to be done in this method. That said....

I think this change might introduce a hidden bug -- one that is not immediately obvious nor experienced but could be if something else changed. The logic here says: "If the delegate does not allow a wpcom login and the site does not have Jetpack, then show the prompt". This works for WordPress.com sites since they do not have Jetpack since the conditional evalutes to false. This works for self-hosted sites that have Jetpack since the conditional evaluates to true. This would fail for self-hosted sites without Jetpack if it was ever evaluated for one. Currently the code path for a self-hosted non-Jetpack site does not encounter this check since the API call results in the failure block being executed. Subtle, eh?

I wonder if a more robust fix would be to just call the unauthenticated endpoint. The connect/site-info results include a filed for isWordPressDotCom which could be checked first. Then if true the delegate could be consulted about whether to allow a dotcom login. Its a larger change but maybe worth it to clarify the work being done (and potentially clean up the other code paths that go through here.)

Thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would fail for self-hosted sites without Jetpack if it was ever evaluated for one
Oh! I didn't realize that.

I'm going to give your proposed solution a try and see if it makes more sense. I love the idea of cleaning this method up a bit.

according to code review.
Tested with self hosted, self hosted with JP, WP site and private WP site.
@yaelirub
Copy link
Contributor Author

@aerych , refactored fetchInfo according to your suggested solution and tested on self hosted, self hosted with JP, WP public and private and all seem to work.
ready for another look.

Copy link
Contributor

@aerych aerych left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Heya Yael! Looking good! Everything tested well. I had two nitpicks but otherwise :shipit:

})
self.configureViewLoading(false)
if siteInfo.isWPCom {
if WordPressAuthenticator.shared.delegate?.allowWPComLogin == true {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Loving the change ❤️.
One nitpick, maybe we could tweak this to do the work with fewer conditionals? Maybe something like

            if siteInfo.isWPCom && WordPressAuthenticator.shared.delegate?.allowWPComLogin == false {
                // Hey, you have to log out of your existing WP.com account before logging into another one.
                self.promptUserToLogoutBeforeConnectingWPComSite()
                return;
            }
            self.presentNextControllerIfPossible(siteInfo: siteInfo)

///
public let icon: String

public let isWPCom: Bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For consistency could we add a comment describing the property? Its pretty obvious but 🤷‍♂.

@yaelirub yaelirub merged commit 8a2f375 into develop May 29, 2019
@astralbodies astralbodies deleted the fix/11526_jetpack_allowedWP_login branch August 26, 2019 13:29
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants