I'm trying to add an in-app subscription to my app and if I understand Google's guidelines correctly, the proper way to validate in-app purchases is as follows:
My app queries active subscriptions from Google's billing API
My app sends active subscription details to my server
My server sends the details to Google, which responds with whether they are valid
My server responds back to my app with whether the details are valid
My app now knows whether the user is legitimately subscribed
I'm not very familiar with network security, but this process is apparently secure because the alternative is to validate the subscription solely in the app which attackers can reverse engineer and figure out the logic behind it. But I fail to see how receiving a yes/no response from my server is better. Couldn't attackers spoof my server's response if they wanted? Or at least modify the code where the yes/no response is interpreted?
Related
I need to be able to consume a purchase without an Android client being connected using a backend server. Is this possible? If not, why? I am trying to make it possible to process a purchase entirely without a user being connected in the case of a disconnection.
Do I need to send a message to my client from my server requesting consumption and then provide a response to the server when the purchase is consumed? This is what I am trying to avoid.
I see various other similar questions but they are for the AIDL API which is now discontinued for google-in-app billing.
Relative API(s);
https://mvnrepository.com/artifact/com.google.apis/google-api-services-androidpublisher/v3-rev103-1.25.0
SOLUTION: To my knowledge, at this current time, July 2019, it is not possible to consume a purchase from a server. It is only possible from the android client.
This means that the flow of the purchase depends on a request to a client and an response from the client, followed by a required GET to validate the purchase has actually been consumed.
I am using mqtt and mosquito broker to build a simple instant chat for an android platform. Now I wanted to implement a condition where any client can check if another client is online.
I know about Last will and testament but I wanted a user to be detected offline only wen the application is inactive or the user is not currently using the app.
I actually dnt need any code, buh wanted an idea as to how to implement this and I would be much grateful.
You can do this without relying on MQTT internals which is much easier in my view. With this approach, you have much more control over what is going on:
The client can periodically send a message within another topic to inform the server of its availability. In case the server does not receive that message after a specified amount of time, it can assumed that it is offline.
The client can also send another message if the user logs out and inform the server a well.
If you insist on using MQTT internal structure, you may find this question useful:
How to Find Connected MQTT Client Details
I have an application with a dedicated user registration and login system, where I'd like to integrate GCM for downstream messaging.
My question would be now what the best practice/approach would be to do so. I could either
use one single GCM token across all user sessions
or request a new GCM token upon a login and try to unregister it upon the logout ("try to" because there might be no network connection)
I could imagine pros and cons for both approaches but lack the in-depth GCM experience to say which one would be better.
Anything else I missed?
I would prefer to keep a single GCM token for multiple users. When you send the push notification send a custom node as username or userid to which you want to send the notification.
When you actually receive the notification check for the currently logged-in user and if it matches with the node passed in push notification then show the notification to the user and if it doesn't discard it (or store it locally to be displayed when that user logs in).
In practical scenario one phone will be used by only one user (with very few exceptions may be), so you shouldn't worry about saving it either. But that could be a business decision.
Update
Google very clearly says that after un-registering and again registering for GCM token may be same. So there is no point in un-registering and registering for GCM again and again. Here is the snippet of official document.
A registration token isn't associated with a particular logged in user. If the client app unregisters and then re-registers, the app can receive the same registration token or a different registration token.
Official Documentation
I am looking for some guidelines as to how to secure requests from android client to server
How can i prevent un autenthic (users which initiate requests not from the android app) requests to be accepted and processed by the server?
Waybe generate token at user registration and use it somehow at each call?
My server is a lite instance and performance is top issue in the implementation of the server client communication.
Appreciate any help!
You could use Google Cloud Messaging as a via medium to make sure messages that reach your server are from the app, without getting too involved in details. Check the documentation here:
https://developer.android.com/google/gcm/index.html
Or else, as you said, create a unique id on registration and send it back to the client. Store it at both client and server. Now with each request from the client, add an extra field in the request and send the id also. Check this id serverside and make sure it is valid (this check could eventually become heavy on time).
I'm currently developing an android app where the user has to fill out and successfully send the data of a few text fields to a recipient/server, to enable a feature.
The big issue is how to do that in a secure way to be protected against e.g. decompiling. My concern is not the security during the transport but rather the security of the transport medium.
What I've thought/read so far:
I could send the data via mail with the Java Mail API.
First of all, I don't want require that the user has to enter his mail credentials and SMTP server.
That would mean that I have to include the credentials to a mail account in the app, though.
To avoid the situation that somebody decompiles the app and takes over my mail account, I thought of encrypting methods, but even if I would save the aes encrypted version of the password, the attacker could decompile the app and could add a syso to output the decrypted password.
The same applies to OAuth authentication because I have to store an authentication token.
In addition to the mail version, I read something about getting the password with a POST request from a web service, which doesn't seem safer at all.
I could search for free smtp server without the need of credentials, but I want something I can rely on instead of waking up each day and looking if the service still works.
Send the data to a web service.
Okay that would require more work for me, but I would accept that, if there would be a solution without saving the credentials in the app or having a web service which accepts data from everybody.
Have I overlooked something? Or is there no safe method without asking the user for his mail credentials or google account etc. ?
OAuth would probably work. The nice thing about OAuth is that if a token is compromised it can be revoked on the server side.
You could create a web service that accepts TCP connections on some port. You could have some authentication mechanism for example Digest authentication that would be carried out before accepting data.
Another option would be to use an API such as Golgi. Golgi requires a developer key, app key and app instance id to connect to the servers and send data. In the event these credentials somehow get compromised you can simply change the app key and push a new version of the app through the Play Store.