flutterfire icon indicating copy to clipboard operation
flutterfire copied to clipboard

feat(app-check): Debug token support for the activate method

Open furkankurt opened this issue 10 months ago • 12 comments

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.

furkankurt avatar Jan 06 '25 12:01 furkankurt

👍 +1

thiago-salonkee avatar Jan 15 '25 15:01 thiago-salonkee

@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 avatar Jan 15 '25 17:01 russellwheatley

@russellwheatley Do you know when this would be accepted and merged? It's a really nice idea!

MirceaX2Mobile avatar Jan 27 '25 17:01 MirceaX2Mobile

@MirceaX2Mobile - I have raised the question, I'm waiting for a response.

russellwheatley avatar Jan 27 '25 18:01 russellwheatley

Any update for my PR, @russellwheatley ?

furkankurt avatar Feb 11 '25 19:02 furkankurt

@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 avatar Feb 12 '25 11:02 russellwheatley

@russellwheatley Seems it's been a while, any new updates on this? Thanks!

jxng1 avatar Apr 23 '25 16:04 jxng1

Would be nice to hear some updates, this feature would be so helpful @russellwheatley

MirceaX2Mobile avatar Apr 26 '25 19:04 MirceaX2Mobile

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 🙏

russellwheatley avatar Apr 28 '25 08:04 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 🙏

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.

chaudharydeepanshu avatar May 05 '25 11:05 chaudharydeepanshu

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 😄

russellwheatley avatar May 13 '25 09:05 russellwheatley

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 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 😄

Thanks for the update @russellwheatley, I’ll go ahead and implement the updated structure:

  • Mark existing enum params as deprecated
  • Add providerAndroid, providerApple (mirroring existing webProvider)
  • 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 🚀

furkankurt avatar May 13 '25 10:05 furkankurt

Is this PR still active?

kurtmarcink avatar Jul 10 '25 16:07 kurtmarcink

@furkankurt Really appreciate this one. It is really important for anyone with flutter and CI. Are you still updating this or can anyone else?

asaworld avatar Jul 14 '25 08:07 asaworld

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

MirceaX2Mobile avatar Jul 14 '25 18:07 MirceaX2Mobile

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 :)

furkankurt avatar Jul 14 '25 22:07 furkankurt

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 :-)

asaworld avatar Jul 25 '25 09:07 asaworld

Yeah, this would be a big help! I've also been able to test it and use it in my testing builds.

SimonPrague avatar Jul 25 '25 21:07 SimonPrague

Can we get this pushed through and released? Pretty important for anyone with integration tests.

asaworld avatar Aug 04 '25 21:08 asaworld

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

Bigboer avatar Aug 12 '25 11:08 Bigboer

Hey folks, we are going looking into this PR and will have a response soon 🙏

russellwheatley avatar Aug 12 '25 13:08 russellwheatley

@furkankurt Do you have time to look into this?

MirceaX2Mobile avatar Sep 10 '25 22:09 MirceaX2Mobile

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 avatar Nov 15 '25 23:11 juliancoronado

@juliancoronado - yes, this would be better as an issue so we can track it if it is a bug 👍

russellwheatley avatar Nov 18 '25 10:11 russellwheatley