react-native-google-fit
react-native-google-fit copied to clipboard
Help with going to production (infinite loading popups, and inability to request user permission)
First of all, let me mention that I have read the guide about the demo setup (here: https://github.com/StasDoskalenko/react-native-google-fit/blob/master/docs/INSTALLATION.md#demo-walkthrough), and I also read the responses at #258
I have the same issue as with #258, but only in Production (while waiting for Google to verify my OAuth Consent Screen).
Even if Google has granted access to my account as a test user so that I can create a YouTube video showing how I am using the scopes (yes, they ask for that!), I am stuck in #258, which should work (but with a warning for production users that the application is not verified yet by Google).
I know that this problem may fall out of scope, but I do have some questions regarding the use of react-native-google-fit
- Regarding the guide, don't we need to give Google the appropriate scopes that we use, to complete the verification? The guide seems to indicate that we can go to production without those scopes provided.
- Regarding the library, for Android 10+, should we ask for the user's permission first like here: https://developers.google.com/fit/android/authorization before asking the
react-native-google-fit
to authorize the application, from here? https://developers.google.com/fit/android/authorization - In here: https://developers.google.com/fit/android/get-started#build_and_test_your_app in the "Resulting user authorization flow" it states that part of the flow is to request for permissions first, and THEN call for Oauth scopes - does
react-native
google-fit` cover that part for later versions of Android?
Thank you.
@csotiriou let see what happen after the verification. If it works out well, maybe you could leave your progress here, Then I can add it into the documentation with your review, along with next major change .
OK - so let me post back with my findings.
Google did not provide a clear answer as to why this was happening. They have asked me for a video of the application using those scopes, and this was giving me a hard time since while the OAuth consent screen was submitted for production and awaiting verification, I would end up having the issue in #258.
I have tried replicating the issue in #258 with my consent screen in testing mode, and with another dummy application setup, using only native code. I was able to reproduce the exact same behavior in testing mode, by creating the screen, without adding any test users. And voila! Infinite loader! I added a test user during the testing mode, the problem disappeared. I submitted the consent screen for production, the problem appeared again.
I concluded that the problem would have to do with the test user setup.
What I did to overcome this, was that I took down the OAuth Consent Screen, I took a video with the consent screen in testing mode (but with my production application from the play store running on a real device - this is very important, you need to be honest with the video and the build you are using), and I resubmitted the OAuth consent screen again.
As far as the technical aspects:
- I used React Native Permissions to ask for the appropriate permissions from the user according to the documentation, and then I called
react-native-google-fit
to get the OAuth consent. - That means that I also added some permissions regarding the fitness activities that I was requesting to my manifest file.
@csotiriou May I conclude that the only reason you bypassed the loader is simply because Google finally verified your application.
Test mode is test mode, not matter how you work with it, you would not like to use it in production. As I said in #258, you made your own app into production does not mean anything for Google. So as long as you are not verified and want to use google native(android) api, you are going to be infinite loader regardless it's react-native or native.
@csotiriou I confirm in #258 production application. It's you must be verified by google in my case for video review Google responded to me https://developers.google.com/identity/branding-guidelines#top_of_page with some things and I fixed and recorded it again without switching from production to test mode but my first video is in test mode and It works Google responded request granted for me.
Please check SHA-1 on your production application's already add-in credentials screen
https://support.google.com/cloud/answer/9110914#verification-requirements&zippy=%2Cwhat-are-the-requirements-for-verification
I followed everything in this link.
@csotiriou I confirmed in #258 production application. It's you must be verified by google in my case for video review Google responded to me https://developers.google.com/identity/branding-guidelines#top_of_page with some things and I fixed and recorded it again without switching to test mode but my first video is in test mode and It's works Google reponsed request granted for me.
Please check SHA-1 on your production application's already add-in credentials screen
https://support.google.com/cloud/answer/9110914#verification-requirements&zippy=%2Cwhat-are-the-requirements-for-verification I followed everything in this link.
If everything works flawless, it's time to add/improve some doc for installation part.
@csotiriou I confirm in #258 production application. It's you must be verified by google in my case for video review Google responded to me developers.google.com/identity/branding-guidelines#top_of_page with some things and I fixed and recorded it again without switching from production to test mode but my first video is in test mode and It works Google responded request granted for me.
Please check SHA-1 on your production application's already add-in credentials screen
support.google.com/cloud/answer/9110914#verification-requirements&zippy=%2Cwhat-are-the-requirements-for-verification I followed everything in this link.
Thank you!
The only thing I miss in this case, is this: If you are not yet verified for production, then how would you be able to record a video while your consent screen is in production? I get that your first video was in test mode, but you mentioned that your next video was in production mode. Therefore, since you were not yet verified, how were you able to record a functioning video?
@csotiriou Sorry, for making confused Production for me is mean "Publishing stage" in OAuth consnet screen. I run my application for recorded video in local.
- This's what I response to Google.
- This's attached file in email.
Don't forget to change your Youtube URL in OAuth consent screen.
Just a note for everyone that may make their review process more difficult. As mentioned in installation instructions:
docs/INSTALLATION.md
Create credentials
1). Credential Type Fitness API, check userdata 2). OAuth Consent Screen Add your App name (it can be any but it will show up the name when asking authentication in your app) Add email 3). Scopes (optional) Skip this part since we can ask permission in App. ...
No need to add scopes! The OAuth works as expected in production
Just a note for everyone that may make their review process more difficult. As mentioned in installation instructions:
docs/INSTALLATION.md
Create credentials 1). Credential Type Fitness API, check userdata 2). OAuth Consent Screen Add your App name (it can be any but it will show up the name when asking authentication in your app) Add email 3). Scopes (optional) Skip this part since we can ask permission in App. ...
No need to add scopes! The OAuth works as expected in production
Actually, this may not work. This is what google tells you when setting up the Oauth Consent Screen without any scopes setup;
the application may be in production, but Google mentions that not all features will be available. And indeed, this is what happens:
The above screenshop is from within the Android application. Therefore google evaluates your OAuth screen setup at runtime, checks if your consent screen has the authority to request the scopes that you are asking for, and shows a warning if it doesn't. I don't believe there is a way around this.
In this example I have requested the scopes: fitness.activity.read
, and fitness.heartrate.read
, which have both been made restricted
lately (they were previously sensitive
).
If you have managed to do this, and request permissions for fitness.activity.read
, can you please share your configuration that also works in production without a warning from Google?
From your screenshots I can see that your app is not verified ( I guess in Google play store ) so complete this step too. I have provided policy links and logo icon in google console as a setup. Review process took about 2 weeks. When a user wants to use the app, it is required to give access to scopes through the OAuth consent screen.
If I find any problem with this setup I will inform you.
Hello @stratosEft,
To test this theory, I passed the google verification with an application containing only a logo and the title.
Google, however still shows the screen about an unverified application. And indeed, they clarified in the email that getting approval for the brand does not meant that they give approval to the entire Oauth screen and the scopes. The scopes inside the Oauth consent screen must match the scopes requested by your application during runtime.
Hi @csotiriou ,
this message will always be present for testing tracks in google play store (such as internal testing). Have you tried an open testing track or production? No issues for me with the setup described above.
Just a note for everyone that may make their review process more difficult. As mentioned in installation instructions: docs/INSTALLATION.md
Create credentials 1). Credential Type Fitness API, check userdata 2). OAuth Consent Screen Add your App name (it can be any but it will show up the name when asking authentication in your app) Add email 3). Scopes (optional) Skip this part since we can ask permission in App. ...
No need to add scopes! The OAuth works as expected in production
Actually, this may not work. This is what google tells you when setting up the Oauth Consent Screen without any scopes setup;
the application may be in production, but Google mentions that not all features will be available. And indeed, this is what happens:
The above screenshop is from within the Android application. Therefore google evaluates your OAuth screen setup at runtime, checks if your consent screen has the authority to request the scopes that you are asking for, and shows a warning if it doesn't. I don't believe there is a way around this.
In this example I have requested the scopes:
fitness.activity.read
, andfitness.heartrate.read
, which have both been maderestricted
lately (they were previouslysensitive
).If you have managed to do this, and request permissions for
fitness.activity.read
, can you please share your configuration that also works in production without a warning from Google?
Hey did you found any workaround for this??
Now that scope "sensitivity" has changed, you cannot avoid following google's OAuth evaluation and comply with their terms. You may even need a legal team to help you with the policies to be submitted, depending your project's complexity.