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

[SigninSilent only] CommonCore interface for XPC silent request. #1482

Open
wants to merge 21 commits into
base: dev
Choose a base branch
from

Conversation

kaisong1990
Copy link
Contributor

@kaisong1990 kaisong1990 commented Feb 22, 2025

Proposed changes

  1. Added necessary files to start up and connect to the XPC service (these files will be reused for other XPC requests, e.g., interactive).
  2. The entire XPC flow is guarded by an enum and is disabled by default. The XPC mode can be enabled through the Mac MSAL Test app.
  3. Added end-to-end support for the Sign-in silent XPC flow. This requires an additional Broker XPC service to run for tests.
  4. Refactored/extracted common code and added MSIDSSORemoteSilentTokenRequest, which can be used for both silent XPC and silent SsoExtension requests.
  5. Refactored the logic in MSIDRequestControllerFactory to better handle the choice of which controller to use.

Type of change

  • Feature work
  • Bug fix
  • Documentation
  • Engineering change
  • Test
  • Logging/Telemetry

Risk

  • High – Errors could cause MAJOR regression of many scenarios. (Example: new large features or high level infrastructure changes)
  • Medium – Errors could cause regression of 1 or more scenarios. (Example: somewhat complex bug fixes, small new features)
  • Small – No issues are expected. (Example: Very small bug fixes, string changes, or configuration settings changes)

Additional information

@kaisong1990 kaisong1990 requested a review from a team as a code owner February 22, 2025 00:09
@@ -499,6 +499,15 @@
23FB5C452255A11D002BF1EB /* MSIDClaimsRequest.m in Sources */ = {isa = PBXBuildFile; fileRef = 23FB5C24225517AA002BF1EB /* MSIDClaimsRequest.m */; };

Choose a reason for hiding this comment

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

This pull request does not update changelog.txt.

Please consider if this change would be noticeable to a partner or user and either update changelog.txt or resolve this conversation.

@kaisong1990 kaisong1990 force-pushed the kasong/2914053-common-interface branch from 4fc4cb4 to 5603852 Compare February 26, 2025 19:32
@kaisong1990 kaisong1990 changed the title [WPI] CommonCore interface for XPC, silent token request only [SigninSilent only] CommonCore interface for XPC silent request. Feb 26, 2025
#import "MSIDXpcSilentTokenRequestController.h"
#endif

static NSString *newXpcController = @"new_xpc_controller";
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Should this be static const NSString *newXpcController?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, this is not used , removed

{
if (parameters.msidXpcMode != MSIDXpcModeDisable)
{
return [self v2SilentControllerForParameters:parameters
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO, I would avoid using v1, v2 etc in the naming of things. As time goes by what the versions mean relies of anecdotal knowledge and gets lost. Also, this implies that there will be new versions in the future like v3, v4 etc.

I would suggest renaming v2SilentControllerForParameters: as xpcEnabledSilentControllerForParameters or add a new argument like isXpcEnabled to the original method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated the method name. The ending goal is to remove the v1 and to use v2. For now I changed the name to reflect the purpose

error:(NSError *__autoreleasing*)error
{
// Nested auth protocol - Reverse client id & redirect uri
if ([parameters isNestedAuthProtocol])
Copy link
Contributor

Choose a reason for hiding this comment

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

I think duplicate code from 'v1' method here can be refactored

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not do the partial refactoring because I am planning to move to new v2 completely. I will do refactoring for duplicate code if the methods needs to be co-exist all the time.

tokenRequestProvider:tokenRequestProvider
fallbackInteractiveController:fallbackController
error:error];
if (parameters.msidXpcMode == MSIDXpcModeFull || parameters.msidXpcMode == MSIDXpcModeOverride)
Copy link
Contributor

Choose a reason for hiding this comment

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

What about parameters.msidXpcMode == MSIDXpcModeBackup? In such a case, fallbackInteractiveController will be fallbackController

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct
in the condition parameters.xpcMode == MSIDXpcModeFull || parameters.xpcMode == MSIDXpcModeOverride
the xpcController is set to nil

So in MSIDXpcModeBackup condition, the xpcController is not set to nil, and will be used as a fallbackInteractiveController when creating MSIDSSOExtensionSilentTokenRequestController (L188)

Sorry the fallbackInteractiveController is really misleading as this is silent request. I will modify the name in a different PR as it is from old code and XPC unrelated.

tokenRequestProvider:tokenRequestProvider
fallbackInteractiveController:fallbackController
error:error];
if (!silentController) return nil;
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we log error if silentController is nil?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I put the level as warning as this is unexpected

error:error];
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we log when fallbackController is nil?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added


+ (BOOL)canPerformRequest
{
if (@available(macOS 13, *)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: Does return @available(macOS 13, *); work here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, I saw patterns and tested myself that when running on macOS 15, this doe return true as expected

@@ -108,6 +108,9 @@
#pragma mark - SSO context
@property (nonatomic) MSIDExternalSSOContext *ssoContext;

#pragma mark - Xpc Mode
@property (nonatomic) MSIDXpcMode msidXpcMode;
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: I don't think msid prefix is required in the name of the property here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

removed

NSBundle *mainBundle = [NSBundle mainBundle];

// Retrieve the bundle identifier
NSString *bundleIdentifier = [mainBundle bundleIdentifier];
Copy link
Contributor

Choose a reason for hiding this comment

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

Curious to know if there are 2 apps with the same bundle id on the device, which app will the xpc redirect to?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question.

The bundle_id passed here is only for XPC service to identify if the self-claimed app the same as the app bundle from signed cert.

The redirect/reply is not controlled by this, but through connection object. Thinking of ESTS, if there are 2 applications with same bundle calling into ests, ests knows how to reply each app as the apps have different connections/channels to ests

parameters.allowUsingLocalCachedRtWhenSsoExtFailed = YES;

NSError *error;
SEL selectorForMSIDSSOExtensionSilentTokenRequestController = NSSelectorFromString(@"canPerformRequest");
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 not sure if we had decided to not use swizzling in tests or not. I think the way was to create a mock test controller or override this method in test 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.

I believe the protocol/mockl should be the way for future. For this existing test class, I was following the swizzling pattern from upper tests.

@kaisong1990 kaisong1990 requested a review from ameyapat March 13, 2025 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants