-
Notifications
You must be signed in to change notification settings - Fork 37
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
base: dev
Are you sure you want to change the base?
Conversation
@@ -499,6 +499,15 @@ | |||
23FB5C452255A11D002BF1EB /* MSIDClaimsRequest.m in Sources */ = {isa = PBXBuildFile; fileRef = 23FB5C24225517AA002BF1EB /* MSIDClaimsRequest.m */; }; |
There was a problem hiding this comment.
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.
4fc4cb4
to
5603852
Compare
#import "MSIDXpcSilentTokenRequestController.h" | ||
#endif | ||
|
||
static NSString *newXpcController = @"new_xpc_controller"; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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]) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added
There was a problem hiding this comment.
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]; | ||
} | ||
} | ||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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, *)) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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]; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
Proposed changes
MSIDSSORemoteSilentTokenRequest
, which can be used for both silent XPC and silent SsoExtension requests.MSIDRequestControllerFactory
to better handle the choice of which controller to use.Type of change
Risk
Additional information