Closed curtis-sq-chan closed 1 year ago
Hello @curtis-sq-chan,
This behavior would be expected if incoming/outgoing data restriction policy is applied to Edge and/or the receiving app. The Intune SDK filters the launch options on openURL calls for non-exempt apps as a protection from sharing a restricted url. Could you send logs to me at abasore@microsoft.com? With the logs I can verify if this is expected based on policy applied.
@abasore
Sent!
I am not quite following your comment... So the launch options should be empty in the receiving app even through the receiving app is integrated with the Intune SDK? The recieiving app is managed though so why should it be filtered out from the launch options in that case.
Hello @curtis-sq-chan
Looking at the logs, the outgoing share policy is set to restrict sharing and the URL is restricted. In this launch scenario this is expected behavior, unless the URL is set as an exception (see policy options 'Select universal links to exempt' and 'Unmanaged Browser Protocol'). The SDK restricts the data before sending protected data out of the app. Later in the launch sequence the SDK un-restricts the data if the application is protected.
@abasore
On your point about unrestricting the data later in the launch sequence, it is fair to stay it is a technical limitation of the Intune SDK then? That is is not able to unwrap at the method didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
but later if the app is protected. It would be awesome to have support for this to unwrap links in that method as there doesn't seem to be a clear way to make sure the RN JS code is ready to consume linking events before Intune SDK fires the openURL
method.
@curtis-sq-chan Yes, you are exactly correct. This would be a limit of the SDK. Thank you for the input! I've made a note for our team that this is a limit for React users.
Describe the bug: Empty launch options dictionary when launching our Intune SDK integrated app via a URL link with custom scheme (foo-intunemam://foo://blahblah) produced by MAM protected Edge.
-(BOOL)application:(UIApplication*)application didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
in AppDelegateIf Edge is configured to exempt the custom scheme, launch options dictionary is properly populated with URL. For example, Edge produces foo://blahblah (not wrapped by foo-intunemam) which is used to launch the app instead.
App is a react-native app and requires launch options to be populated for the Linking.getInitialURL() to function properly, see https://reactnative.dev/docs/linking#2-if-the-app-is-not-already-open-it-is-opened-and-the-url-is-passed-in-as-the-initialurl
After application:didFinishLaunchingWithOptions is done executing, it is noticed the Intune SDK does subsequently fire with the missing unwrapped (inner?) URL in the scenario described above with this function:
-(BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey, id> *)options
That works fine if the app is already running in background for a while, but it will not work for the fresh launch scenario where app is closed prior. On fresh launch, Javascript app component is not ready to listen for that event as it needs time to get fully initialized hence why a properly populated launch options with URL must be passed to RTCBridge initialization.
To Reproduce Steps to reproduce the behavior:
Expected behavior: launch options dictionary is populated with the unwrapped URL (foo://something) from protected Edge for application:didFinishLaunchingWithOptions in AppDelegate
Smartphone (please complete the following information):
Intune App SDK for iOS (please complete the following information):
What version of the Intune SDK are you using? 17.4 Are you using the latest version? Yes
What platform is your app based in (native, Xamarin based, Cordova, etc)? React-native
Who is the customer? N/A
Do you see a trend with it only being reproduced on a specific device? No
Additional context: Add any other context about the problem here.