flutterfire
flutterfire copied to clipboard
feat(app-check): Debug token support for the activate method
Description
This feature enables developers to use a pre-generated debug token rather than generating one at runtime. It is particularly beneficial in CI environments where manually copying the token from logs and pasting it into the Firebase Console is not feasible. By using a pre-generated token, the setup becomes more automated and less error-prone, streamlining the development and testing process. This PR is an improved version of #13101. Since the maintainer doesn't follow his PR, I wanted to improve it and open another PR. The improvements include better spelling and an added documentation section for how to add a debug token.
Related Issues
Fixes #11719
Checklist
- [X] I read the Contributor Guide and followed the process outlined there for submitting PRs.
- [X] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
- [X] All existing and new tests are passing.
- [X] I updated/added relevant documentation (doc comments with
///). - [X] The analyzer (
melos run analyze) does not report any problems on my PR. - [X] I read and followed the Flutter Style Guide.
- [X] I signed the CLA.
- [X] I am willing to follow-up on review comments in a timely manner.
Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?
- [ ] Yes, this is a breaking change.
- [X] No, this is not a breaking change.
👍 +1
@furkankurt - thank you for the PR! Looks good and something worthwhile IMO. I have asked the question to the Firebase team if this is something we can move ahead with. I will circle back when I have feedback 👍
@russellwheatley Do you know when this would be accepted and merged? It's a really nice idea!
@MirceaX2Mobile - I have raised the question, I'm waiting for a response.
Any update for my PR, @russellwheatley ?
@furkankurt - I'm still waiting for feedback I'm afraid. We will get an answer at some point, it'll just take a bit of time. Thank you for your patience 🙏
@russellwheatley Seems it's been a while, any new updates on this? Thanks!
Would be nice to hear some updates, this feature would be so helpful @russellwheatley
Quick update - We're currently in discussion about this feature and how best to implement it. We're not sure about the current way to pass in the debug token, ideally, it would be passed in via some form of debug class instance rather than a separate argument (as currently implemented on this PR), but this would constitute a breaking change. I will update here once a final decision has been made 🙏
Quick update - We're currently in discussion about this feature and how best to implement it. We're not sure about the current way to pass in the debug token, ideally, it would be passed in via some form of debug class instance rather than a separate argument (as currently implemented on this PR), but this would constitute a breaking change. I will update here once a final decision has been made 🙏
One question: Are we considering flutter web also in that discussion for this feature support?
Rightnow for flutter web we can add the script tag in the index.html to pass the debug token. I was thinking if in that new approach we could do this from dart code for web-app then it would be easier to use.
Hey @furkankurt - we have the green light for this feature. It has been agreed that the existing enum arguments for activate() will be annotated as deprecated (to be removed in a future, breaking change release next year), new arguments for android and iOS will be implemented (this is a tough one, the names as they currently stand would be ideal androidProvider and appleProvider, maybe rename them to be providerAndroid and providerApple? 🤔 ). They will follow the same pattern as webProvider which you can see here: https://github.com/firebase/flutterfire/blob/main/packages/firebase_app_check/firebase_app_check_platform_interface/lib/src/web_providers.dart#L5
Essentially an abstract base class which is extended by the different providers (e.g. for Apple; base class would be extended by these: https://github.com/firebase/flutterfire/blob/main/packages/firebase_app_check/firebase_app_check_platform_interface/lib/src/apple_provider.dart#L10-L19).
Hopefully that makes sense, let me know if you need any further information and if you are willing to continue with this PR! Thank you 😄
Hey @furkankurt - we have the green light for this feature. It has been agreed that the existing enum arguments for
activate()will be annotated as deprecated (to be removed in a future, breaking change release next year), new arguments for android and iOS will be implemented (this is a tough one as the names as they currently stand would be idealandroidProviderandappleProvider, maybe rename them to beproviderAndroidandproviderApple? 🤔 ). They will follow the same pattern as webProvider which you can see here: https://github.com/firebase/flutterfire/blob/main/packages/firebase_app_check/firebase_app_check_platform_interface/lib/src/web_providers.dart#L5Essentially an abstract base class which is extended by the different providers (e.g. for Apple; base class would be extended by these: https://github.com/firebase/flutterfire/blob/main/packages/firebase_app_check/firebase_app_check_platform_interface/lib/src/apple_provider.dart#L10-L19).
Hopefully that makes sense, let me know if you need any further information and if you are willing to continue with this PR! Thank you 😄
Thanks for the update @russellwheatley, I’ll go ahead and implement the updated structure:
- Mark existing enum params as deprecated
- Add
providerAndroid,providerApple(mirroring existingwebProvider) - Refactor with abstract classes for each platform's providers
- Keep backwards compatibility until next major release
The naming suggestion providerAndroid / providerApple works well for me too. Will update the PR shortly 🚀
Is this PR still active?
@furkankurt Really appreciate this one. It is really important for anyone with flutter and CI. Are you still updating this or can anyone else?
I don't really get it but https://github.com/firebase/flutterfire/pull/13101 was closed and we are back to this PR? So we are waiting for another approval I guess? @russellwheatley
Hey folks, sorry for my late modification but I wasn't able to make it. @russellwheatley I've made the changes you suggested. Feel free to review my changes :)
I can confirm this code works as expected for me on an Android device. I would really love to see this be released to pub.dev.
Of course the next one is DebugWebProvider :-)
Yeah, this would be a big help! I've also been able to test it and use it in my testing builds.
Can we get this pushed through and released? Pretty important for anyone with integration tests.
Also keen for this solution to go in. Have tried everything to get this to work but your solution seems to be the only valid one
Hey folks, we are going looking into this PR and will have a response soon 🙏
@furkankurt Do you have time to look into this?
Hi Firebase / Flutter team! In recently upgrading my firebase_app_check pub package recently, I encountered the changes regarding the provider names and the debug tokens. This is awesome as it's something I've been hoping would be implemented!
That being said, I am not able to get this feature working on iOS devices (namely the iOS simulator on iOS 26.1). It works just as expected on Android but the iOS simulator running my app locally is still receiving this message:
Unhandled Exception: [cloud_firestore/permission-denied] The caller does not have permission to execute the specified operation.
I created the debug token in my Firebase console for iOS and passed it into the new AppleDebugProvider(debugToken: 'token_here') constructor. I haven't found any documentation regarding this new change here either: https://firebase.google.com/docs/app-check/flutter/debug-provider#apple_platforms
Any help would be greatly appreciated! Does anything need to be modified in the ios specific build files? If this would be better suited as an issue, I can create that as well.
@juliancoronado - yes, this would be better as an issue so we can track it if it is a bug 👍