react-native-intune 0.1.1 → 0.1.2

package/android/build.gradle

@@ -93,33 +93,54 @@ gradle.taskGraph.whenReady { graph ->
 }
 
 /**
- * Disable AAR packaging for this library, with a message that says why.
+ * The MAM SDK is resolved through a repository rather than as a file.
  *
- * `./gradlew assembleDebug` from a consumer's android/ directory assembles every module,
- * including this one, and `:react-native-intune:bundleDebugAar` then fails with "Direct
- * local .aar file dependencies are not supported when building an AAR". People run that
- * command, and the error names our library, so it reads as our bug.
+ * `implementation files(mamAar)` is what Microsoft's guide shows for an *app* module, and
+ * in a *library* module AGP rejects it wherever it has to package the library: "Direct
+ * local .aar file dependencies are not supported when building an AAR". This used to be
+ * worked around by disabling the bundle tasks by name, and that could not be made right
+ * across AGP versions — the lint AAR an app's `lintVitalAnalyzeRelease` consumes is built
+ * by one of those tasks. Disabling it broke every clean release build on AGP 8.12;
+ * leaving it enabled breaks the same build on the AGP of React Native 0.74, which applies
+ * the local-.aar rule to the lint AAR too.
  *
- * It is not a workaround for a problem we could otherwise solve. AGP's own message says
- * the AAR "would be broken because the classes and Android resources from any local .aar
- * file dependencies would not be packaged" — so the output being skipped is an output
- * that could never have been correct. The MAM SDK is distributed as a file from
- * Microsoft's GitHub, not from Maven Central, so there is no coordinate to depend on
- * instead.
+ * Resolved from a repository, the SDK is an ordinary module dependency and AGP stops
+ * treating this library as a special case anywhere.
  *
- * Nothing is lost: autolinking consumes this library as a Gradle *project*, so its AAR is
- * never built for a consumer. `:app:assembleDebug` was always the working form; now the
- * root form works too.
+ * An Ivy repository with an `[artifact].[ext]` pattern, because it points at the file
+ * fetch-sdks already wrote, under the exact name Microsoft distributes —
+ * `Microsoft.Intune.MAM.SDK.aar` — with nothing copied or renamed and no metadata to
+ * generate. A flat directory would do the same and prints "should be avoided because it
+ * doesn't support any meta-data formats" on every consumer's build, naming this library.
+ * The version in the coordinate is not in the pattern, so it is informational: the pin in
+ * sdk-versions.json, the one fetch-sdks downloaded.
+ *
+ * The repository has to be visible to the app, not only to this project: the app resolves
+ * its runtime classpath with its own repositories, so a repository declared here alone
+ * would fail there. It is added to every project and made exclusive to the one module, so
+ * nothing else is ever looked up in it and this module is never looked up anywhere else.
  */
-tasks.configureEach { task ->
-  if (task.name ==~ /bundle.*Aar/) {
-    task.enabled = false
-    task.doFirst {
-      logger.lifecycle(
-        "[react-native-intune] Skipping ${task.name}: this library depends on the MAM " +
-        "SDK as a local .aar, so AGP cannot package a valid AAR for it. Consumers " +
-        "autolink it as a Gradle project and never need one."
-      )
+def mamVersion = new groovy.json.JsonSlurper()
+  .parse(file("$projectDir/../sdk-versions.json")).android.tag
+def mamRepoDir = mamAar.parentFile
+rootProject.allprojects {
+  repositories {
+    exclusiveContent {
+      forRepository {
+        ivy {
+          name = "react-native-intune-mam-sdk"
+          url = mamRepoDir.toURI()
+          patternLayout {
+            artifact "[artifact].[ext]"
+          }
+          metadataSources {
+            artifact()
+          }
+        }
+      }
+      filter {
+        includeModule("react-native-intune", "Microsoft.Intune.MAM.SDK")
+      }
     }
   }
 }
@@ -127,7 +148,7 @@ tasks.configureEach { task ->
 dependencies {
   implementation "com.facebook.react:react-android"
 
-  implementation files(mamAar)
+  implementation("react-native-intune:Microsoft.Intune.MAM.SDK:${mamVersion}@aar")
 
   // MSAL. Mirrored in sdk-versions.json -> toolchain.msal_android; change both together.
   //

package/android/src/main/java/com/reactnativeintune/RNIntunePackage.kt

@@ -16,17 +16,22 @@ class RNIntunePackage : BaseReactPackage() {
   }
 
   override fun getReactModuleInfoProvider() = ReactModuleInfoProvider {
+    // Positional, not named. In React Native 0.74 `ReactModuleInfo` is still a Java
+    // class, and Kotlin cannot pass named arguments to a Java constructor — the named
+    // form compiles only on versions where the class was rewritten in Kotlin, so it
+    // failed on 0.74 while building everywhere this was developed. The six parameters
+    // are in the same order in both.
     mapOf(
       RNIntuneModule.NAME to ReactModuleInfo(
-        name = RNIntuneModule.NAME,
-        className = RNIntuneModule.NAME,
-        canOverrideExistingModule = false,
+        RNIntuneModule.NAME, // name
+        RNIntuneModule.NAME, // className
+        false, // canOverrideExistingModule
         // The event emitter must be live from construction, not from the first
         // enroll() — a service-initiated wipe can arrive before JS calls anything
         // (SPEC §4.4, §12.4). Revisit this flag when the emitter lands.
-        needsEagerInit = false,
-        isCxxModule = false,
-        isTurboModule = true
+        false, // needsEagerInit
+        false, // isCxxModule
+        true, // isTurboModule
       )
     )
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "react-native-intune",
-  "version": "0.1.1",
+  "version": "0.1.2",
   "description": "Microsoft Intune app protection policies (MAM) for React Native",
   "main": "./lib/module/index.js",
   "types": "./lib/typescript/src/index.d.ts",
@@ -22,7 +22,7 @@
     "app.plugin.js",
     "plugin",
     "scripts",
-    "!scripts/verify-expo.mjs",
+    "!scripts/verify",
     "sdk-versions.json",
     "sdk-lock.json",
     "!vendor",
@@ -44,7 +44,8 @@
   ],
   "scripts": {
     "fetch-sdks": "node scripts/fetch-sdks.mjs",
-    "verify:expo": "node scripts/verify-expo.mjs",
+    "verify:expo": "node scripts/verify/expo.mjs",
+    "verify:bare": "node scripts/verify/bare.mjs",
     "postinstall": "node scripts/fetch-sdks.mjs --soft --quiet",
     "example": "yarn workspace react-native-intune-example",
     "clean": "del-cli android/build example/android/build example/android/app/build example/ios/build lib",

package/plugin/transforms.js

@@ -187,9 +187,55 @@ function addImports(contents, imports) {
   return `${contents.slice(0, at)}\n${missing.join('\n')}${contents.slice(at)}`;
 }
 
+/**
+ * Forwards the sign-in redirect to MSAL from the generated AppDelegate.
+ *
+ * The URL type alone is not enough. When the broker — Authenticator or Company Portal —
+ * finishes, it opens the app with the result, and unless the AppDelegate hands that URL
+ * to MSAL it arrives and is dropped: the sign-in never completes and nothing reports
+ * why. Both halves were needed on a device, and the bare example has always had this
+ * one; the Expo plugin wrote the URL type and not the forward.
+ *
+ * MSAL goes first in the `||` chain, so a redirect meant for it is consumed before
+ * Linking sees it; any other URL falls through unchanged.
+ *
+ * Returns null when there is no `open url` handler to extend — a warning beats an
+ * AppDelegate edited in the wrong place.
+ */
+function withMsalResponseHandler(contents, language) {
+  if (/handleMSALResponse/.test(contents)) {
+    return contents;
+  }
+  const isSwift = language === 'swift';
+
+  const handler = isSwift
+    ? /(func\s+application\s*\(\s*_\s+\w+\s*:\s*UIApplication\s*,\s*open\s+url\s*:\s*URL\s*,\s*options\s*:[^)]*\)\s*->\s*Bool\s*\{\s*\n(\s*)return\s+)/
+    : /(-\s*\(BOOL\)\s*application\s*:\s*\(UIApplication\s*\*\)\s*\w+\s+openURL\s*:\s*\(NSURL\s*\*\)\s*url\s+options\s*:[^{]*\{\s*\n(\s*)return\s+)/;
+  if (!handler.test(contents)) {
+    return null;
+  }
+  const forward = isSwift
+    ? 'MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[.sourceApplication] as? String) || '
+    : '[MSALPublicClientApplication handleMSALResponse:url sourceApplication:options[UIApplicationOpenURLOptionsSourceApplicationKey]] || ';
+  let next = contents.replace(handler, `$1${forward}`);
+
+  const importLine = isSwift ? 'import MSAL' : '#import <MSAL/MSAL.h>';
+  const imports = isSwift
+    ? /^(?:\w+\s+)?import\s+\w+.*$/gm
+    : /^#import\s+.*$/gm;
+  const lastImport = [...next.matchAll(imports)].pop();
+  if (!lastImport) {
+    return null;
+  }
+  const at = lastImport.index + lastImport[0].length;
+  next = `${next.slice(0, at)}\n${importLine}${next.slice(at)}`;
+  return next;
+}
+
 module.exports = {
   MARKER,
   withMamPluginApplied,
   withMamClasspath,
   withMamApplication,
+  withMsalResponseHandler,
 };

package/plugin/withIntune.js

@@ -37,6 +37,7 @@ const {
   createRunOncePlugin,
   withAndroidManifest,
   withAppBuildGradle,
+  withAppDelegate,
   withEntitlementsPlist,
   withInfoPlist,
   withMainApplication,
@@ -48,6 +49,7 @@ const {
   withMamApplication,
   withMamClasspath,
   withMamPluginApplied,
+  withMsalResponseHandler,
 } = require('./transforms');
 
 const pkg = require('../package.json');
@@ -169,6 +171,30 @@ const withMsalUrlScheme = (config, { maxFileProtectionLevel, keychainGroup }) =>
     return c;
   });
 
+/**
+ * The other half of the URL type. Without it the broker's redirect reaches the app and
+ * is dropped, and sign-in never completes — see withMsalResponseHandler.
+ */
+const withMsalRedirectForward = (config) =>
+  withAppDelegate(config, (c) => {
+    const result = withMsalResponseHandler(
+      c.modResults.contents,
+      c.modResults.language
+    );
+    if (result === null) {
+      WarningAggregator.addWarningIOS(
+        MARKER,
+        'Could not forward the MSAL redirect in AppDelegate — no open-URL handler ' +
+          'was recognised. Sign-in through Authenticator or Company Portal will not ' +
+          'return to the app until this is done by hand. Run ' +
+          '`npx react-native-intune doctor` for the exact change.'
+      );
+      return c;
+    }
+    c.modResults.contents = result;
+    return c;
+  });
+
 // ---------------------------------------------------------------- android
 
 const withBrokerQueries = (config) =>
@@ -305,6 +331,7 @@ const withIntune = (config, props = {}) => {
   let next = config;
   next = withKeychainGroups(next, { keychainGroup });
   next = withMsalUrlScheme(next, { maxFileProtectionLevel, keychainGroup });
+  next = withMsalRedirectForward(next);
   next = withBrokerQueries(next);
   next = withRedirectActivity(next, { androidSignatureHash });
   next = withGradle(next);

package/scripts/lib/checks.mjs

@@ -24,6 +24,7 @@
 
 import { execFileSync } from 'node:child_process';
 import fs from 'node:fs';
+import path from 'node:path';
 import { read, rel } from './project.mjs';
 
 const MARKER = 'react-native-intune: managed block';
@@ -462,7 +463,161 @@ pinning an older MAM SDK whose row you do match — see sdk-versions.json.`,
 
 // ---------------------------------------------------------------- ios
 
+/**
+ * The lowest iOS the vendored MAM SDK runs on. Read from the binary (`otool -l` on
+ * IntuneMAMSwift.framework in the 21.8.0 drop reports `minos 17.0`), not from
+ * Microsoft's release notes — the SDK should move this, not a guess.
+ */
+const MIN_IOS = [17, 0];
+
+const versionAtLeast = (value, [major, minor]) => {
+  const [a = 0, b = 0] = String(value).split('.').map(Number);
+  return a > major || (a === major && b >= minor);
+};
+
+/**
+ * The deployment target each configuration of each application target actually builds
+ * with: the target's own setting, or the project-level one it inherits when it sets
+ * none. A value elsewhere in the file — a project-level default the target overrides,
+ * another target — says nothing about what the app is built for, and counting those is
+ * how an Expo project, whose project level reads 16.4 while the app target reads 17.0,
+ * was reported as wrong.
+ */
+function appDeploymentTargets(pbxproj) {
+  const object = (isa) =>
+    new RegExp(
+      `(\\w{24})\\s*(?:/\\*[^*]*\\*/)?\\s*=\\s*\\{\\s*isa\\s*=\\s*${isa};([\\s\\S]*?)\\n\\t\\t\\};`,
+      'g'
+    );
+  const configs = new Map();
+  for (const [, id, body] of pbxproj.matchAll(object('XCBuildConfiguration'))) {
+    configs.set(id, {
+      name: body.match(/\bname\s*=\s*"?([^";]+)"?;/)?.[1],
+      value: body.match(/IPHONEOS_DEPLOYMENT_TARGET\s*=\s*"?([\d.]+)"?;/)?.[1],
+    });
+  }
+  const lists = new Map();
+  for (const [, id, body] of pbxproj.matchAll(object('XCConfigurationList'))) {
+    const ids = body.match(/buildConfigurations\s*=\s*\(([^)]*)\)/)?.[1] ?? '';
+    lists.set(id, [...ids.matchAll(/\w{24}/g)].map((m) => m[0]));
+  }
+  const listOf = (body) => body.match(/buildConfigurationList\s*=\s*(\w{24})/)?.[1];
+
+  const [, , projectBody = ''] = [...pbxproj.matchAll(object('PBXProject'))][0] ?? [];
+  const inherited = new Map(
+    (lists.get(listOf(projectBody)) ?? []).map((id) => [
+      configs.get(id)?.name,
+      configs.get(id)?.value,
+    ])
+  );
+
+  const effective = [];
+  for (const [, , body] of pbxproj.matchAll(object('PBXNativeTarget'))) {
+    if (!/productType\s*=\s*"com\.apple\.product-type\.application"/.test(body)) {
+      continue;
+    }
+    for (const id of lists.get(listOf(body)) ?? []) {
+      const c = configs.get(id) ?? {};
+      effective.push({ name: c.name, value: c.value ?? inherited.get(c.name) ?? null });
+    }
+  }
+  return effective;
+}
+
+/** Ruby comments — whole-line or trailing — so a commented-out platform line is ignored. */
+const stripRubyComments = (src) => src.replace(/(^|\s)#.*$/gm, '$1');
+
 const iosChecks = [
+  {
+    id: 'ios-deployment-target',
+    platform: 'ios',
+    title: `Deployment target is iOS ${MIN_IOS.join('.')} or later`,
+    severity: 'loud',
+    /**
+     * React Native's template targets `min_ios_version_supported` — 15.1 — and the SDK
+     * is built for 17.0, so a new project fails at `pod install` before anything else
+     * here can be tried. The Podfile and the Xcode target are read separately because
+     * they disagree independently: a raised Podfile with a 15.1 app target installs the
+     * pod and builds, then crashes at launch on any iOS 16 device it was allowed onto.
+     */
+    inspect(project) {
+      const podfile = stripRubyComments(read(project.ios.podfile));
+      if (!podfile) {
+        return { state: 'unknown', detail: 'ios/Podfile not found' };
+      }
+      const line = podfile.match(/^\s*platform\s+:ios\s*,\s*(.+)$/m)?.[1]?.trim();
+      if (!line) {
+        return { state: 'unknown', detail: 'no `platform :ios` line in the Podfile' };
+      }
+
+      let target = line.match(/^['"]([\d.]+)['"]$/)?.[1];
+      let source = 'Podfile';
+      if (!target && /ios\.deploymentTarget/.test(line)) {
+        // Expo's generated Podfile reads Podfile.properties.json first, which is what
+        // expo-build-properties writes, and falls back to the template minimum.
+        const props = path.join(path.dirname(project.ios.podfile), 'Podfile.properties.json');
+        try {
+          target = JSON.parse(read(props) || '{}')['ios.deploymentTarget'];
+          source = 'Podfile.properties.json';
+        } catch {
+          return { state: 'unknown', detail: 'Podfile.properties.json is not valid JSON' };
+        }
+        if (!target) {
+          return {
+            state: 'wrong',
+            detail:
+              'ios.deploymentTarget is not set, so the Podfile falls back to ' +
+              'min_ios_version_supported',
+          };
+        }
+      }
+      if (!target) {
+        return /min_ios_version_supported/.test(line)
+          ? {
+              state: 'wrong',
+              detail: 'the Podfile uses min_ios_version_supported, which is below 17.0',
+            }
+          : { state: 'unknown', detail: `cannot read a version from: ${line}` };
+      }
+      if (!versionAtLeast(target, MIN_IOS)) {
+        return { state: 'wrong', detail: `${source} targets ${target}` };
+      }
+
+      const effective = appDeploymentTargets(read(project.ios.pbxproj));
+      if (effective.length === 0) {
+        return {
+          state: 'unknown',
+          detail: `${source} targets ${target}; no application target found in the Xcode project`,
+        };
+      }
+      // A configuration that sets it nowhere builds for the SDK's own default, which is
+      // the newest iOS — not a problem, so only explicit low values count.
+      const low = effective.filter((e) => e.value && !versionAtLeast(e.value, MIN_IOS));
+      if (low.length > 0) {
+        return {
+          state: 'wrong',
+          detail:
+            `${source} targets ${target}, but the app target builds for ` +
+            low.map((e) => `${e.value} (${e.name})`).join(', '),
+        };
+      }
+      return { state: 'ok', detail: `${source}: ${target}` };
+    },
+    why:
+      'MAM SDK 21.x is built for iOS 17.0. Below it CocoaPods refuses the pod; with only ' +
+      'the Podfile raised, the app builds and then crashes at launch on older devices it ' +
+      'still claims to support.',
+    instruction: () =>
+      `In ios/Podfile:
+
+    platform :ios, '17.0'
+
+  and set Minimum Deployments to 17.0 on your app target in Xcode
+  (IPHONEOS_DEPLOYMENT_TARGET), then run pod install again.
+
+  Expo: set it with expo-build-properties — { "ios": { "deploymentTarget": "17.0" } }.`,
+  },
+
   {
     id: 'ios-keychain-groups',
     platform: 'ios',