I'm getting this email from Google developers who remembers me to migrate to Play Integrity API.
My app is built using react-native and it uses rnfirebase library for Authentication, storage, and a few other services. We are not using AppCheck directly.
I could see the SafetyNet library inside my app which is being internally used by Firebase Auth.
There is an issue already open in the rn-firebase repo. The discussion there concludes to wait a bit more till the migration is done at the library side.
So my question is should I wait till it is done or can I do something from my side and will my app stop working after January 30th?
You can read the complete email from here
Related
I have an old project which I still find useful that was originally built with Google Cloud Messaging, that I then had to convert to use Firebase Cloud Messaging. I haven't worked on it for years but find it useful for my friends to track my phone's position via a web page on my always-on Raspberry Pi.
I received an e-mail from Google Analytics which said
You are receiving this email because you own one or more Firebase
projects using Google Analytics. With the release of Google Analytics
4 properties, to keep using your Firebase projects with Google
Analytics, you must take action to accept the Google Analytics Terms
of Service for the following projects:
I tried following the upgrade instructions via the console and get a failure due to an internal error
To the best of my knowledge I don't use any of the analytics stuff, so my question is quite simple:
"Will my existing messaging to my phone from my web page still work?"
firebaser here
Sorry to hear about the problem you have when upgrading your project to GA4. Our team is aware of the problem, and working on a fix, so I recommend trying again in a few hours. Meanwhile check this page for status updates.
Firebase Cloud Messaging relies on Google Analytics data to build its dynamic audiences, which you can target when sending notification from the Firebase console. If you don't use dynamic audiences, you don't need Google Analytics to use Firebase Cloud Messaging.
Hello to all of you guys.
Today I received the following warning from Google to my inbox :
We are writing to let you know that Google will discontinue support for sign-ins to Google accounts from embedded browser frameworks, starting January 4, 2021.
We have detected the use of an embedded browser framework with one or more of your OAuth clients that may be blocked on or after January 4, 2021. Please review your use of Google Account authorization flows in the following Google OAuth client IDs and make any required changes before January 4, 2021...
In my project, I am using the official google sign-in library to authenticate a user and retrieve user's account and token. When user is logged in and token is successfully retrieved, token is send to backend server in order to generate the access & refresh token as described in the OAuth2 flow.
My question is, is there a conflict using both these flows to finally generate an access token for the user? If not, do you have any ideas where I should focus to locate and fix the problem? As the warning says, I am not using any embedded browser login functionallity so my concirns are on the previously described case.
Thank you in advance!
Google's recommendation for some time has been for mobile apps to follow the AppAuth pattern, where the app itself never sees the user's credentials and a Chrome Custom Tab is used for logins.
If you are interested in evaluating this option there are a couple of code samples from my blog that you can easily run. It is quite a difficult flow to implement though.
Google AppAuth Sample
Advanced AppAuth Sample
We received this error in our Google play console recently:
ACTION REQUIRED: Your server-side billing confirmations will stop working on December 1, 2019
Your app is using an old version of the Google Play Developer API. From December 1 2019, versions 1 and 2 of this API will no longer be available, and any calls to these versions will fail. Update to version 3 before this date. Note that this is not related to the AIDL/Billing Library deprecation. Learn more
However, we are currently using the correct API version3 in our server to validate our in app purchase billing receipts. An in app purchase library we're using also exposes the functionality in client side, and I've confirmed their source code is also making use of v3. Both are calling request to https://www.googleapis.com/androidpublisher/v3/applications/...
We've had real purchases be validated in production so I know it's functional and I'm trying to understand where the source of problem is.
I also read here that it might be due to third party plugins.
If anything we've recently integrated Facebook SDK which said it could do android receipt validation for us to make sure it's not reporting any fraud/sandbox purchases.
Has anyone else encountered this action required sign? If so, what steps did you take to eliminate/resolve it, and were they related to third party plugins that were using the androidpublisher apis?
Might be you are using
https://www.googleapis.com/androidpublisher/v1/applications/
For validating purchase replace V1 with V3
https://developers.google.com/android-publisher/api-ref/purchases/subscriptions/get
for validating purchase receipt from server side.
Will importing a Google Project into Firebase interfere with or break the operation of any legacy applications using the related APIs? For example, we currently use the Youtube APIs to allow users to upload videos to a website. Would this be affected after migrating?
It shouldn't break the legacy applications since the API key etc will remain the same. I've migrated the Google Project to Firebase project. I used to use Google Cloud Messaging API. Now I migrated from GCM to FCM (Firebase Cloud Messaging) and the projectId, projectNumber or SenderID, API Key, all remained the same. I didn't have to change anything on the server side as well and it worked out of the box.
Also if you import your Google Cloud Project to Firebase Project, the project on Google Cloud Platform still remains and you can keep using the same API's for now in similar manner. It seems that only for GCM, Google App Invites and AdMob, you can 'choose' to upgrade to corresponding Firebase services.
Lately, I have been working a lot with Google APIs on Android especially Analytics, AdSense and Tasks API.
I have seen some samples provided by Google where they use this statement to obtain a GoogleAccountCredential object
https://code.google.com/p/google-api-java-client/source/browse/tasks-android-sample/src/main/java/com/google/api/services/samples/tasks/android/TasksSample.java?repo=samples
credential =
GoogleAccountCredential.usingOAuth2(this, Collections.singleton(TasksScopes.TASKS));
However, If I go through the documentation such as:
http://developer.android.com/google/auth/http-auth.html
http://developer.android.com/google/play-services/auth.html
Both of them mention the below method to be used for obtaining a token:
token = GoogleAuthUtil.getToken(mActivity, mEmail, mScope);
I am confused which one to use in which scenario and why. I have been using Method no. 1 successfully and without the need of persisting the token in preferences (I guess this is done by GoogleAccountCredential automatically)
Can anyone tell me why would anyone use the first method as opposed to second ?
How can I access the auth token in the first method ?
The Google APIs Client Library for Java is as the name suggests a library for accessing Google APIs and it is available for several platforms such as Java (in general) and Android while the Google Play Services and GoogleAuthUtil is only available on Android.
By looking at the wiki page of the project it is difficult to understand how Google APIs Client Library relates to GoogleAuthUtil since the wiki suggests that the AccountManager is used for handling Google accounts and it doesn't really mention GoogleAuthUtil at all.
However if you dig into the code and their issue tracker a bit you can see that the tasks sample you linked actually uses GoogleAuthUtil since version 1.12.0 of the Google APIs Client Library when support for GoogleAuthUtil was added.
The wiki is probably mention the AccountManager instead of GoogleAuthUtil since that was the way to do OAuth2 authentication before GoogleAuthUtil was available and because that part of the wiki has not been updated yet.
For more information on the differences between the AccountManager and GoogleAuthUtil please see: In a nutshell what's the difference from using OAuth2 request getAuthToken and getToken
In short Google APIs Client Library is a cross platform library for interacting with Google's services and the Android version is implemented by using GoogleAuthUtil.
Can anyone tell me why would anyone use the first method as opposed to second ?
Reasons for using Google APIs Client Library
If you are developing for some other platform than Android you can not use GoogleAuthUtil as it is an Android specific library.
If you are developing a cross platform application you can use the Google APIs Client Library in your shared code for for both Android and other platforms.
If you interact a lot with many of Google's services this library may make things easier for you.
If you are already using this and it works as wanted there isn't really any drawback to continue using it as it is a wrapper for GoogleAuthUtil so you get all the advantages of GoogleAuthUtil compared to using the AccountManager or some other library based on the AccountManager.
Reasons for using GoogleAuthUtil
Using this requires no other libraries or external dependencies than the Google Play Services
Your app's footprint should be smaller since you don't have to include additional libraries.
If your interaction with Google is limited it might be easier to just use the GoogleAuthUtil directly instead of going trough another library.
GoogleAuthUtil shouldn't be that hard to use as it is, so using a library that wraps around it to simplify it might not be that much easier to use.
I am confused which one to use in which scenario and why. I have been using Method no. 1 successfully ...
If you are using the Google APIs Client Library and it works fine for you I don't see any reason why you shouldn't continue using it.
However if I would create an Android (only) application that needed to interact with Google's services I would probably use GoogleAuthUtil directly.
... without the need of persisting the token in preferences (I guess this is done by GoogleAccountCredential automatically)
Yes I this is automatically handled by GoogleAuthUtil which is in turn used by GoogleAccountCredential.
How can I access the auth token in the first method ?
You should be able to call the method getToken() on the GoogleAccountCredential object.
Google Play Services client library is written specifically for Android devices to offer a seamless integration with individual Google services and a consistent user interface to obtain authorization from users to access these services with their credentials.
Google APIs Client Library for Java is a generic library to access Google Services from all application types (web, installed, or Android application).
Coming back to Android, if the Google API you want to use is not included in the Google Play services library, you can connect using the appropriate REST API, but you must obtain an OAuth 2.0 token.
To obtain a token, you can either -
directly use the OAuth 2.0 library from Google APIs Client Library for Java (not preferred for android)
or leverage the authorization portion of the Google Play services library using GoogleAuthUtil and AccountPicker. Read Authorizing with Google for REST APIs. (GoogleAuthUtil.getToken() caches and manages token expiry and refresh itself. However, in case of network errors/server load, you might need to use an exponential back-off algorithm before retrying for the token so to not flood the server with requests.)
or use the GoogleAccountCredential packaged in google-api-client-android-1.19.0.jar that comes with Google APIs Client Library for Java. The package offers Utilities based on Google Play services client libraries and GoogleAccountCredential is just a wrapper around GoogleAuthUtil and AccountPicker. This would allow you to use the same consistent authorization flow and the standard account picker dialog that comes Google Play services client library while delegating the token management to GoogleAccountCredential. Refer this for an example.
Method number one (com.google.api.client.googleapis.extensions.android.gms.auth.*) is part of Google's more general, cross platform account management flow, while method number two (com.google.android.gms.auth.GoogleAuthUtil) is Android specific. It looks like the various Android Google APIs, method two, wrap and simplify method one. For instance, the Google+ documentation, second paragraph, states "The Google+ Sign-In button authenticates the user and manages the OAuth 2.0 flow, which simplifies your integration with the Google APIs."
I would the Android specific method, token = GoogleAuthUtil.getToken(mActivity, mEmail, mScope), wherever possible.