Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove knowledge of AppConfiguration from WPAccount Objective-C #24231

Merged
merged 2 commits into from
Mar 20, 2025

Conversation

mokagio
Copy link
Contributor

@mokagio mokagio commented Mar 17, 2025

Part of #24165.

Similarly to #24230 , pushing knowledge of app-target-related types out of WPAccount helps us cutting all the threads that prevent the type from being moved out of the app target and into WordPressData.

Tested by running on WordPress on device and smoke testing.

@dangermattic
Copy link
Collaborator

dangermattic commented Mar 17, 2025

1 Warning
⚠️ This PR is assigned to the milestone 25.9. The due date for this milestone has already passed.
Please assign it to a milestone with a later deadline or check whether the release for this milestone has already been finished.

Generated by 🚫 Danger

[sharedDataIssueSolver migrateAuthKeyFor:username];
}
SharedDataIssueSolver *sharedDataIssueSolver = [SharedDataIssueSolver instance];
[sharedDataIssueSolver migrateAuthKeyFor:username];
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Notice that moving isJetpack into SharedDataIssueSolver would not have severed the thread because, as you can see, SharedDataIssueSolver is used in WPAccount and therefore needs to be moved to WordPressData as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

It is possible to move the entire + (NSString *)tokenForUsername:(NSString *)username isJetpack:(BOOL)isJetpack implementation to the app target?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not easily, because unfortunately it is used to get the authToken property in WPAccount (also used by Blog, which reads it from its .account).

There are ~30 usages in the production codebase between blog and account (based on a quick Search, maybe there's more), which made me hopeful in extracting it. But there's also code like this that sets the expectation for having a token stored in the model object.

        [self.coreDataStack performAndSaveUsingBlock:^(NSManagedObjectContext *context) {
            WPAccount *account = [context existingObjectWithID:accountObjectID error:nil];
            // Even if we find an account via its userID we should still update
            // its authtoken, otherwise the Authenticator's authtoken fixer won't
            // work.
            account.authToken = authToken;
        }];

So, I'm not super confident in taking off to remove it just yet.

static func tokenForUsername(_ username: String) -> String {
token(forUsername: username, isJetpack: AppConfiguration.isJetpack)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure whether the +Lookup extension is the best where to host this implementation, but it will do for now. "token for username" kind feels like looking up information, no?

static func tokenForUsername(_ username: String) -> String {
token(forUsername: username, isJetpack: AppConfiguration.isJetpack)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Also, @kean I am aware that AppConfiguration is due for removal and that isJetpack should be removed in favor of an enum. I don't know when that's going to happen, though, so I just kicked the can down the road.

After all, this is a net zero change. I doesn't remove an AppConfiguration usage but it doesn't add one either. It simply moves it from one place to another.

@mokagio mokagio added this to the 25.9 milestone Mar 17, 2025
@mokagio mokagio added the Core Data Issues related to Core Data label Mar 17, 2025
@mokagio mokagio self-assigned this Mar 17, 2025
@mokagio mokagio requested review from crazytonyli and kean March 17, 2025 04:39
@mokagio mokagio marked this pull request as ready for review March 17, 2025 04:39
@wpmobilebot
Copy link
Contributor

wpmobilebot commented Mar 17, 2025

WordPress Alpha📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.
App NameWordPress Alpha WordPress Alpha
ConfigurationRelease-Alpha
Build Numberpr24231-7bfce84
Version25.8
Bundle IDorg.wordpress.alpha
Commit7bfce84
App Center BuildWPiOS - One-Offs #11752
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@wpmobilebot
Copy link
Contributor

wpmobilebot commented Mar 17, 2025

Jetpack Alpha📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.
App NameJetpack Alpha Jetpack Alpha
ConfigurationRelease-Alpha
Build Numberpr24231-7bfce84
Version25.8
Bundle IDcom.jetpack.alpha
Commit7bfce84
App Center Buildjetpack-installable-builds #10778
Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

@mokagio
Copy link
Contributor Author

mokagio commented Mar 17, 2025

Reverting to draft. Tomorrow I'll investigate the crashes in the tests and UI tests in CI.

@mokagio mokagio marked this pull request as draft March 17, 2025 10:11
@mokagio
Copy link
Contributor Author

mokagio commented Mar 19, 2025

Okay, the issue is that

token(forUsername: username, isJetpack: AppConfiguration.isJetpack)

returns nil and crashes the tests.

Why does it return nil?

Because

    NSString *authToken = [SFHFKeychainUtils getPasswordForUsername:username
                                                     andServiceName:[WPAccount authKeychainServiceName]
                                                        accessGroup:nil
                                                              error:&error];

returns nil without failing.

How was it working before, I wonder... How has the change here surfaced this issue?

@mokagio mokagio force-pushed the mokagio/decouple-wpaccount-appconfiguration branch from 31b232f to aabe8cf Compare March 19, 2025 05:14
@mokagio mokagio force-pushed the mokagio/decouple-wpaccount-appconfiguration branch from aabe8cf to 7bfce84 Compare March 20, 2025 01:02
@mokagio mokagio marked this pull request as ready for review March 20, 2025 01:04
@mokagio
Copy link
Contributor Author

mokagio commented Mar 20, 2025

How was it working before, I wonder... How has the change here surfaced this issue?

Simple: The code was allowed to return nil. It was not a problem because of Objective-C and no nullability annotations.

Once we got to Swift, I assumed the value would have been non-nil and typed String instead of String?

@mokagio mokagio enabled auto-merge March 20, 2025 01:05
@mokagio mokagio added this pull request to the merge queue Mar 20, 2025
Merged via the queue into trunk with commit e98ba7e Mar 20, 2025
25 checks passed
@mokagio mokagio deleted the mokagio/decouple-wpaccount-appconfiguration branch March 20, 2025 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Data Issues related to Core Data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants