Support platform attestation in the SDK and sample#8
Conversation
|
Warning Review limit reached
Next review available in: 42 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughAdds optional platform attestation configuration to the Flutter SDK, with Android Play Integrity and iOS App Attest token providers, native wiring, updated dependencies, quickstart configuration, documentation, and serialization tests. ChangesPlatform attestation
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
android/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.kt (1)
150-162: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winReject enabled Android attestation without a project number.
A missing value becomes
0Land still initializesPlayIntegrityTokenProvider; token minting then fails only during a flow. ThrowIAMException(ThunderIDErrorCode.INVALID_CONFIGURATION, ...)when attestation is enabled and the number is null/non-positive.Proposed fix
val attestationEnabled = args["attestationEnabled"] as? Boolean ?: false -val cloudProjectNumber = (args["cloudProjectNumber"] as? Number)?.toLong() ?: 0L +val cloudProjectNumber = (args["cloudProjectNumber"] as? Number)?.toLong() +if (attestationEnabled && (cloudProjectNumber == null || cloudProjectNumber <= 0)) { + throw IAMException( + ThunderIDErrorCode.INVALID_CONFIGURATION, + "cloudProjectNumber is required when Android attestation is enabled", + ) +} ... - PlayIntegrityTokenProvider(context, cloudProjectNumber)::requestToken + PlayIntegrityTokenProvider(context, cloudProjectNumber!!)::requestToken🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@android/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.kt` around lines 150 - 162, Update the ThunderIDConfig construction in the method handling attestation configuration to preserve the raw cloudProjectNumber value, validate it before creating PlayIntegrityTokenProvider, and throw IAMException with ThunderIDErrorCode.INVALID_CONFIGURATION when attestationEnabled is true and the number is missing or non-positive. Continue using the validated positive project number for token provider initialization.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@ios/Classes/AppAttestTokenProvider.swift`:
- Around line 23-31: Update AppAttestTokenProvider’s failure handling so
AppAttestError.unsupported is converted to the SDK’s typed error contract using
ThunderIDErrorCode and IAMException before crossing the platform channel.
Preserve the unsupported-device distinction and ensure other provider failures
continue mapping to their appropriate typed operational errors rather than
UNKNOWN_ERROR.
- Around line 49-56: The attestation tokens are not bound to the individual
server request, and iOS marks keys attested before backend acceptance. In
ios/Classes/AppAttestTokenProvider.swift lines 49-56, update requestToken to
accept and use the server-issued challenge instead of calling makeChallenge; in
ios/Classes/AppAttestTokenProvider.swift lines 84-87, defer marking the key
attested until the backend confirms the attestation; in
android/src/main/kotlin/dev/thunderid/flutter/PlayIntegrityTokenProvider.kt
lines 41-43, set requestHash on StandardIntegrityTokenRequest using the
request-specific flow data.
In `@ios/thunderid_flutter.podspec`:
- Line 15: Update the ThunderID dependency declaration in the podspec from the
broad ~> 0.2 constraint to ~> 0.2.0, keeping iOS installs aligned with the
Android v0.2.0 dependency.
---
Outside diff comments:
In `@android/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.kt`:
- Around line 150-162: Update the ThunderIDConfig construction in the method
handling attestation configuration to preserve the raw cloudProjectNumber value,
validate it before creating PlayIntegrityTokenProvider, and throw IAMException
with ThunderIDErrorCode.INVALID_CONFIGURATION when attestationEnabled is true
and the number is missing or non-positive. Continue using the validated positive
project number for token provider initialization.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: fee84550-5d98-4fcf-9672-97e7c52d536e
📒 Files selected for processing (11)
android/build.gradleandroid/src/main/kotlin/dev/thunderid/flutter/PlayIntegrityTokenProvider.ktandroid/src/main/kotlin/dev/thunderid/flutter/ThunderIDMethodHandler.ktios/Classes/AppAttestTokenProvider.swiftios/Classes/ThunderIDMethodHandler.swiftios/thunderid_flutter.podspeclib/src/models/thunderid_config.dartsamples/quickstart/.env.examplesamples/quickstart/README.mdsamples/quickstart/lib/main.darttest/thunderid_client_test.dart
e419cee to
3ee54d8
Compare
1 participant
Purpose
Add platform attestation support to the Flutter SDK and sample, following the native iOS and Android work (thunder-id/thunderid#4126).
Approach
The Flutter SDK is a thin wrapper over the native SDKs, so the attestation token is minted natively and driven by config flags from Dart:
ThunderIDConfiggainsattestationEnabledandcloudProjectNumber, passed to native viatoMap().Attestation-Tokenheader on native flow-initiate requests.ThunderID 0.2, Androidandroid-sdks v0.2.0) and added the Play Integrity dependency.THUNDERID_ATTESTATION_ENABLED/THUNDERID_CLOUD_PROJECT_NUMBERand documented the setup.End-to-end attestation still depends on the server issuing the challenge and verifying the token — tracked separately.
Related Issues
Related PRs
Checklist
Security checks
Summary by CodeRabbit