We have developed the app and published the google play store then received the notification from Google like as following.
'We found that your app uses software that contains security vulnerabilities for users. Apps with these vulnerabilities can expose user information or damage a user’s device, and may be considered to be in violation of our Malicious Behavior policy'
'Your app(s) are using an unsafe implementation of the HostnameVerifier interface. You can find more information about how resolve the issue in this'
We need to resolve this before the deadline 1 January 2021.
Please, help me how to solve this issue?
Related
BACKGROUND INFO
I have developed an application in R through the shiny package, and deployed it online through the shinyapps.io service.
Among its different functions, the shiny app can send emails (through my personal Google Account) to users if the fill a form. The emails are sent through the functionalities of the gmailr package, and to make it work I had to follow the procedure on the Google Cloud Platform to create a JSON token, configure the OAuth consent screen, and store the credentials I obtain in a folder of my R project. All the steps to this process are reported at the end of this GitHub issue I opened a while ago.
THE PROBLEM
The JSON token I generated on the Google Cloud Platform expires after some days.
After googling around, I noticed that this can happen if my "Application", on Google Cloud, is still in the Testing phase. First question about this statement:
What does it mean when Google refers, on the OAuth screen, as an Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
In addition, on the Google's OAuth consent screen, I now have the possibility to "publish" such application. If I do that, the status changes as In production, and this message is displayed. Other questions:
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
What will happen to users that try to connect to my application?
Are my credentials, as for example the JSON file, safe?
I know that there might be a lot of confusion in this post, but I am relly not an expert in this field, and so I am worried to make some mistakes.
Thanks a lot for your help!
The GMail API, OAuth and all, is typically meant to allow your app to send email on behalf of any user. It seems your use-case is a little different - you only ever need to connect one user: your own.
What does it mean when Google refers, on the OAuth screen, as an **Application in Testing phase? My application is already online on shinyapps.io, it's already functioning, and when I create a new token it can also send emails correctly (for a while).
I think you mostly answered this yourself in your further questions. Google thinks you're building an app that any GMail user can connect to, and so for security reasons, they want to differentiate between a test app and a production app. They don't necessarily know whether or not your app is published on shinyapps.io.
What does it mean that the application will be available to everyone with a Google account? My application deployed on shinyapps.io doesn't require any login or any other data from the users, then what is this app they're talking about?
I alluded to this earlier, but the GMail API is intended for apps that allow any GMail user to connect and manipulate their own email. Imagine a third-party email client, or similar. Again - Google's wording sounds a bit odd wrt your app since it doesn't fit that bill.
What will happen to users that try to connect to my application?
If you don't explicitly host your own server that implements OAuth with Google, then nobody can even try to connect. As long as you don't leak the shared secret from your Google Cloud Platform entry, you're safe.
Are my credentials, as for example the JSON file, safe?
Probably anyone with the JSON file can send email on your behalf. Marking your app as 'in production' will not change the security implications of your JSON file.
Unfortunately, Google has pretty tight security around their APIs nowadays. If you want to mark your app as "in production" you might open up a can of worms regarding "restricted scopes" (sending email counts as restricted). However, since you're using the JSON file instead full OAuth, I'm not sure if this applies to you. To my knowledge, you should be safe to try marking your app as "in production". Worst-case scenario, you might be able to weasel around the strict verification requirements by saying your app is "internal":
Internal Use: The app is used only by people in your Google Workspace or Cloud Identity organization. Note that your app will not be subject to the unverified app screen or the 100-user cap if it's marked as Internal.
Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
Update: Google Bug Report Description
(as suggested by google dev advocate in comments on answer 1, filed a bug report; updating the content here since it more succinctly and precisely describes the problem)
I do not need or want to show any notifications to my user. And many users are not willing to give notifications permission because they assume they will start seeing notifications.
But I wish to push data to my web page from the server. The web page is active and in the foreground. This is the classic use case that Web Sockets were designed for.
I understand that I could write my own web socket server and somehow try to scale it, or go to some other third-party for an outsourced scalable web socket push solution.
But, isn't this is a very common "sub-use-case" of the messaging that Firebase Messaging is targeted towards? Therefore shouldn't Google support this use case? I can't see any fundamental technical show-stoppers, but since Google is so smart, please do enlighten me if I am missing something on why this cannot or should not be done.
Original StackOverflow Question Text:
I don't need background notifications or service workers. All I want is to send data to the web page when it is currently loaded and in the foreground.
Websockets do not need any permission but they need a websocket server and maintenance. It is difficult or expensive to scale it.
Firebase solves the problem fundamentally but I don't see why it must require a user to give notifications permission even though I only want to push data when the page is loaded; not in the background.
The problem is that Firebase Messaging is only using 1 method to deliver notifications. That is the Push API specification spec, and that specification (wrongly and unfortunately) does not allow a service worker to receive messages without the user allowing an unrelated permission to show notifications.
The fix would be for the Firebase Messaging team to provide a different way to deliver messages to active web pages -- long polling, or websockets.
But it would be extra work for them, and may be not enough people are requesting it.
It's to protect the user's preferences about what your app is allowed to do. The way push messaging works on browsers is by using a service worker. Even though you say you don't need a service worker, you are actually making using of it when using Firebase Cloud Messaging in your app.
Given that, the prompt is necessary because the browser doesn't know what you intend to do with that push message. If the user doesn't trust your app, they should have the right to limit what it can actually do, especially when they're not using your app. Mobile operating systems (iOS, Android) are the same way.
Our Android application is working over 2000 devices on field. This is a corporate app, not published on Google Play and we are managing our operations via these devices. Most important point for us: All of our client Android devices are behind proxy. (We have already take all actions on Firebase document warning about "If your organization has a firewall...")
We are testing to adapt FCM to our app for receiving notifications. We are using HTTP Protocol, sending Post requests to https://fcm.googleapis.com/fcm/send URL address, so our choice is Downstream HTTP Messages (JSON) and we are sending data messages both via Postman and also via our .Net desktop app. Firebase Cloud Messaging notifications are working successfully when device is connected to Internet via independent WiFi. It is also working successfully when device is connected to Internet via mobile network operator SIM card (No Proxy). But these methods are not a solution for us, because all of our devices are working behind proxy.
Is Firebase Cloud Messaging notifications not working on devices behind proxy? I found some bad news about FCM and behind proxy devices, but I am not sure. We want to use FCM notifications, however 3rd party extra apps is not a good solution for us. Because we are managing too many devices on field and we have also security issues. Is there any alternative solution to solve this issue about proxy?
I have received an answer from Firebase support team about this question. The answer is below:
Please note that FCM do not support Proxy at the moment, however we
will take a note of this and we could consider it moving forward. I
can't give you a definite timeline for this, rest assured your
feedback has been acknowledged. We are constantly working on providing
developers a more friendly experience hence your inputs are greatly
appreciated.
We have spent some effort and time with our app development and network team about this Proxy issue. Please note that FCM do not support Proxy at this time. I hope they can support Proxy in the future, because FCM have many benefits.
If you took the actions described in if your organization has a firewall
then the devices should be able to receive the messages.
https://firebase.google.com/docs/cloud-messaging/server#response
Please note that those action have to be taken in the network where the devices are connected, not in the network where the notification is sent.
Please note that as of 2019 Firebase has some Proxy Support, at least using Java or Node.js, see this Article about it: https://medium.com/faun/firebase-accessing-firestore-and-firebase-through-a-proxy-server-c6c6029cddb1
In case the Link is down, this is an example for Java configuration, all credits go to Hiranya Jayathilaka who wrote this great Tutorial (many thanks!)
String myProxyHost = "localhost"; // REPLACE
int myProxyPort = 3128; // REPLACE
InetSocketAddress address = new InetSocketAddress(myProxyHost, myProxyPort);
HttpTransport transport = new NetHttpTransport.Builder()
.setProxy(new Proxy(Proxy.Type.HTTP, address))
.build();
FirebaseOptions.Builder builder = new FirebaseOptions.Builder();
builder.setHttpTransport(transport);
// ... further configuration ...
Addition:
I have tried this solution and setting the HttpTransport only proxies requests to "fcm.googleapis.com", which is not sufficient in my case, because the Firebase Sdk first retrieves an Authorization Token from "accounts.google.com".
To Proxy requests to "accounts.google.com" also, I had to use System-Properties like this:
System.setProperty("https.proxyHost", proxyHost);
System.setProperty("https.proxyPort", String.valueOf(proxyPort));
System.setProperty("com.google.api.client.should_use_proxy", "true");
I was going through updated official APNS documentation and it clearly says,
All developers should migrate their remote notification provider servers to the more capable and more efficient HTTP/2-based API described in APNs Provider API.
But the new APNs Provider API doesn't seem to have old APNS Feedback Service. They have changed endpoint URLs which doesn't have feedback service endpoint. Also looks the error codes are upgraded now, which includes below error code,
Unregistered -
The device token is inactive for the specified topic.
So aren't we suppose to call the APNS Feedback service anymore?
My major problem is I'm using javapns api version 2.2 for iOS push notifications for which I'm not able to find any update which will help me to cope up with this new changes.
I think the new doc is clear :
There's an HTTP status code for the case that was previously reported by the Feedback Service :
410 - The device token is no longer active for the topic.
In addition, there's a JSON data key named timestamp in the response body :
timestamp
If the value in the :status header is 410, the value of this key is the last time at which APNs confirmed that the device token was no longer valid for the topic.
Stop pushing notifications until the device registers a token with a later timestamp with your provider.
Therefore, the HTTP response in the new API covers the functionality that was previously covered by the Feedback Service. Since the Feedback Service is not mentioned in the new doc, we can safely assume that it's not part of the new API.
If you are using an old library such as javapns, which still uses the old API, I'm assuming that it still uses the Feedback Service too. The old API is likely to still be supported by Apple for a while.