Skip to content
This repository was archived by the owner on Feb 5, 2025. It is now read-only.
Merged
2 changes: 1 addition & 1 deletion WordPressAuthenticator.podspec
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
Pod::Spec.new do |s|
s.name = "WordPressAuthenticator"
s.version = "1.31.0-beta.1"
s.version = "1.31.0-beta.2"
s.summary = "WordPressAuthenticator implements an easy and elegant way to authenticate your WordPress Apps."

s.description = <<-DESC
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -68,6 +68,14 @@ public protocol WordPressAuthenticatorDelegate: class {
///
func shouldPresentLoginEpilogue(isJetpackLogin: Bool) -> Bool

/// Indicates the Host app wants to handle and display a given error.
Copy link
Contributor Author

@ctarda ctarda Nov 27, 2020

Choose a reason for hiding this comment

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

These two methods would be new. This would break WordPress, but the fix is simple: for host apps that are good with WPAuthenticator's error handling, shoudlDisplayError would just return false, and handleError would do nothing

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for the info! After this is merged, I'll create a WP PR to address this.

///
func shouldHandleError(_ error: Error) -> Bool

/// Signals the Host app that there is an error that needs to be handled.
///
func handleError(_ error: Error, onCompletion: @escaping (UIViewController) -> Void)

/// Indicates if the Signup Epilogue should be displayed.
///
func shouldPresentSignupEpilogue() -> Bool
Expand Down
1 change: 0 additions & 1 deletion WordPressAuthenticator/Signin/LoginViewController.swift
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,6 @@ open class LoginViewController: NUXViewController, LoginFacadeDelegate {
/// Overridden here to direct these errors to the login screen's error label
dynamic open func displayRemoteError(_ error: Error) {
configureViewLoading(false)

let err = error as NSError
guard err.code != 403 else {
let message = LocalizedText.loginError
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -140,6 +140,17 @@ final class SiteAddressViewController: LoginViewController {
}
}

override func displayRemoteError(_ error: Error) {
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 might not be necessary. In fact, I would argue that it would be good to avoid doing it.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm sorry, but I'm confused by this. It appears you added this override method to implement your error handling. Why do you not agree with what you just did? 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry, that was terrible wording on my side. Let me rephrase my comment:

"I am not 100% sure that this is absolutely necessary. So far I have not seen this override being used in any of the tests I have run using WooCommerce. That does not mean it won't happen as I continue testing. I would prefer if, eventually, we noticed that overriding this method is actually unnecessary and we could get rid of the override"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

And I just found a test case for WooCommerce where these overrides are necessary: a Pressable store with Jetpack installed but not activated

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh! OK, that makes more sense. 😄 Thank you sir!

guard authenticationDelegate.shouldHandleError(error) else {
super.displayRemoteError(error)
return
}

authenticationDelegate.handleError(error) { customUI in
self.navigationController?.pushViewController(customUI, animated: true)
}
}

/// Reload the tableview and show errors, if any.
///
override func displayError(message: String, moveVoiceOverFocus: Bool = false) {
Expand Down Expand Up @@ -351,6 +362,19 @@ private extension SiteAddressViewController {
}
}

/// Push a custom view controller, provided by a host app, to the navigation stack
func pushCustomUI(_ customUI: UIViewController) {
/// Assign the help button of the newly injected UI to the same help button we are currently displaying
/// We are making a somewhat big assumption here: the chrome of the new UI we insert would look like the UI
/// WPAuthenticator is already displaying. Which is risky, but also kind of makes sense, considering
/// we are also pushing that injected UI to the current navigation controller.
if WordPressAuthenticator.shared.delegate?.supportActionEnabled == true {
customUI.navigationItem.rightBarButtonItems = self.navigationItem.rightBarButtonItems
}

self.navigationController?.pushViewController(customUI, animated: true)
}

// MARK: - Private Constants

/// Rows listed in the order they were created.
Expand Down Expand Up @@ -419,6 +443,16 @@ private extension SiteAddressViewController {

let err = self.originalErrorOrError(error: error as NSError)

/// Check if the host app wants to provide custom UI to handle the error.
/// If it does, insert the custom UI provided by the host app and exit early
if self.authenticationDelegate.shouldHandleError(err) {
self.authenticationDelegate.handleError(err) { customUI in
self.pushCustomUI(customUI)
}

return
}

if let xmlrpcValidatorError = err as? WordPressOrgXMLRPCValidatorError {
self.displayError(message: xmlrpcValidatorError.localizedDescription, moveVoiceOverFocus: true)

Expand Down Expand Up @@ -480,14 +514,7 @@ private extension SiteAddressViewController {

self.showWPUsernamePassword()
case let .injectViewController(customUI):
/// Assign the help button of the newly injected UI to the same help button we are currently displaying
/// We are making a somewhat big assumption here: the chrome of the new UI we insert would look like the UI
/// WPAuthenticator is already displaying. Which is risky, but also kind of makes sense, considering
/// we are also pushing that injected UI to the current navigation controller.
if WordPressAuthenticator.shared.delegate?.supportActionEnabled == true {
customUI.navigationItem.rightBarButtonItems = self.navigationItem.rightBarButtonItems
}
self.navigationController?.pushViewController(customUI, animated: true)
self.pushCustomUI(customUI)
}
})
}
Expand Down