I develop mobile cross-platform games (for iOS,Android and WP).
I want to know the email or the phone number of the people who bought my app from the iOS,Android or WP store, for using these informations for authentication purpose.
Waiting for your valuable comments and sugessions
Thanks.
You don't have that information unless people authorize you or give it to you.
Under no circumstances should you be able to get the information of the people who are buying your apps unless they opt into it and it’s made crystal clear to them that you are getting this information.
This was in the news last year because you shouldn't have that data.
This counts for iOS and Android.
options
Ask users for their personal information in the app and send it to
your servers.
Make your app need registration and login ( This is very strict on iOS, make sure you have some kind of offerable service which actually need registration)
You can link their personal information with device numbers, but these are spoofable on rooted and jailbroken devices
To get the device information on android:
You want to call android.telephony.TelephonyManager.getDeviceId().
This will return whatever string uniquely identifies the device (IMEI on GSM, MEID for CDMA).
You'll need the
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
permission to do this.
On iOS look at this answer: How to get IMEI on iPhone?
I can only speak for iOS:
You can't get email address nor phone number using iOS APIs. If you want this, you need to ask the user yourself.
Then you'd need a way to verify them:
Email by sending a link they need to click.
Phone number by sending the user an SMS (with link they need to click, or code they need to type in UI), or by calling them and asking them to dial/DTMF a code they see in the app, or on the app enter a code they hear.
If you want to keep users apart, without needing any info from them:
Have a non-consumable in-app payment item (which you could call 'account' for example). Since these items can only be bought once per user, and because Apple's in-app purchase receipt contains a unique ID, you can use this as a user identifier. (If this does not make sense, you need to read Apple's documentation about in-app purchases.)
If you are asking the user for mail/no then just store temperorly and use webservice to retrive in background
If you want the details without knowing to user Use analytics and catch maild id's of user (flurry , google analytics)
I dont think this is possible currently. The playstore console displays information like number of download, carriers, devices, etc. You may want to consider building in those features and requesting the info from the user via the valid permissions. Aside there is an unofficial playstore API that lets you pull data viz. app info, comments, etc. You can find it here
Related
My system consists of a mobile app (a Cordova app), and a webservice, providing all the relevant data. When a user buys the app in the appstore (or playstore, if android), a user account should be created on the webservice, ideally without any user interaction (no registration). The user account could be linked with the gmail account, apple id, ... This is required, to only allow people who have paid to use the webservice.
My Problems:
I did not find a way to get the user id of the user. (Android seems to have a way: https://github.com/loicknuchel/cordova-device-accounts , but iOS not).
I only want exactly one registration per user. This saves me from using something like a registration page, when the app is first started - this could easily be bypassed and lead to multiple registrations.
The user account should be linked to the user and not the device (so no device UUID or so, as this would not be portable between devices).
Ideas that I had:
(Favorite, doesn't seem to be possible) I have a method "getUserID()" in the app, which returns the right user on the phone. Additionally, I have access to an API to check who bought my App. I can easily cross check, to make sure that the user has permission to use the webservice.
(Unnecessary complicated, seems wrong) Make the app free, use a single in-app purchase to buy access to the webservice. When I searched, I found that it seems that in app purchases give you more information, so there might be the chance to link the app with a user.
(Even worse than 2.) Make the app free, use an own payment system/registration.
My question:
What does the Android/iOS app-store eco system provide, so that I can ensure that one user buying the app creates exactly one user account on my webservice, and this user account is linked to the user and not the device?
You should generate a secret api key for each paying user.
Then the user should use this key to auth into your API and get a token back (you can make it expire after some time if you want a stronger protection). User should attach this token to all of his api calls.
I'm making an app, which I will distribute via playstore. However, though the app can be installed by anyone in the world, it can only run for selected users who I know.
Below are the possible ways I have figured out,
Check the account E-Mail ids on the phone and if that matches with the one's saved within the app code.
Check the mobile number on the phone and see if that matches with the one's saved within the app code.
When the app runs for the first time, it will send an SMS to my phone. I will reply to that SMS either saying YES or NO. If I reply YES then only the app will run for that user, else it will not.
I would like your feedback on these mechanisms. If there are other ways let me know about that too.
Thanks...
I think your best options are:
Make users log-in using an e-mail and a password (you could ask the user to register and if he uses an e-mail that is known to you, send a password to that e-mail [make the user change it later though])
Beta testing - This allow you to choose wich users will be able to install your app by creating a community on Google+ to beta test your app.
Maybe both.
Scenario
The user get only the first time free credits in the app. After that we want to do fraud prevention. We need to check if the user and/or the device have not installed the application before.
We can accept the risk of a factory reset or rooted devices
What I tried already
Listen to Intent.ACTION_PACKAGE_FIRST_LAUNCH. After reading I understand that this event is only send to the Play store and can't be used in any other app.
Check the application package info for the field "firstInstallTime", this is reset when the user removed the application and do a install.
Android Backup Service, but the user can stop the backup and reset data, so this is at no use.
App licensing looks like a promise solution to detect if the user have already installed the app. But with limitations the following is described: "You can implement licensing controls for a free app, but only if you're using the service to provide APK expansion files." Do we need to make a small APK expension file, just to verify the license?"
make a fingerprint of the mac address, imei, android id and some other stuff. But would this make the scans of Google play violating? I don't use it for advertising, but i'm afraid they think we violate the google play policy.
how you can help me
Can you help me to choose a good direction to solve this issue and maybe give some better methods to do this verification.
Factory reset, second-hand phones and users with multiple devices will be your main problems.
The only way to uniquely identify a user is an authentication through login/password or OpenId account.
Hey there if you are managing user information at the your server than what you can do is take the IMEI number of the device and send it to your server. It will record the information of the user. Now if he/she uninstall and install app again your app will again send IMEI number at server now you can check the IMEI already present or not, If present then user have already installed your application, more over you can manage same thing from the login ID, but that can be faked by the user. More over it will not violate any thing. User can see while installing in the permissions that your app will get the system information.
I want to be able to sell products (via credit card) to people using my app. It's easy enough to put some EditTexts in and get them to give me their details but the issue is security of course. What is a good way to go about doing secure credit card transactions in app?
My Big Concern - Someone else makes a fake app that looks the same, with the same icon and app name and gets potential users to download their fake app and steal their credit card information. (Can people maybe even have the same developer account name?)
What I know so far - The package names of apps served off Google Play are unique so a user could identify if the package name is not what it should be. This isn't a good solution for the typical user though.
I'm not planning on storing the credit card details or anything. I just want to be able to do once-off card transactions securely. Any advice would be super welcome and receive much upvoting.
All you need to do is be able to work with Authorize.Net's, or any payment gateways, API to make payment.
Authorize.Net - Android SDK
Boku Mobile Billing
Since you stated that you would be selling products to users using your apps I'm assuming you will have the user details stored somewhere in a database yea? Moreover, you will have some sort of authentication using a username and a password so this means that even if someone else makes the exact same app as you did they will not have the user's username and password (assuming you hash your usernames and their passwords) or the real name of the user which he/she provided during sign-up into your app. Even if the hackers are smart and just use a dummy login page, i.e irrespective of the username and password entered you are logged in I'm sure users will be wary if they don't see a message saying "Hi X (real name of the user)" when they sign into your app (provided you have some functionality where you display the user's real name when they are signed into the app, this is pretty easy to implement). Having said all this, I haven't heard of a case where someone duplicated an entire app (which is no mean feat if you make a sophisticated app) simply to steal user's information.
Regarding the issue of securely accepting credit card information from users and charging it, one of the most trusted, industry-accepted and secure way of accepting user details is using Stripe.com . What's more is that they have a nice RESTful API through which you can make calls and charge the requisite amount from a user's credit card in the safest manner possible. The advantage of this is that you don't have to store the credit card information anywhere and simply use it once to make a call to the Stripe API (which is available in Java btw).
I would like to publish an Android app with 2-years time support (this is due to API costs). After 2 years, the user has to buy the app again (if he wants).
There are at least 3 problems:
I want it to be easy and effortless for the user: so no "registration form" (if possible).
The app should work on other devices connected with the same Google account (as every payed app).
The app should not work if the user sells his device: so using device's IMEI isn't a very good solution.
I think that the definitive solution would be univocally identifying the user, but the question is: how to do that?
Do you think that AccountManager could be a solution?
Note that the app needs to connect to my server in order to work, so the solution can be implemented both client and/or server side.
You can try to uniquely identify the user using his/her phone number. This is what Wavesecure does.
This does have some implications:
a) your app cannot work on a wifi only tablet.
b) you will have to provide a way for users to migrate phone numbers in case they happen to change phones.
You said that:
The app should work on other devices connected with the same Google account (as every payed app).
Use the google account.
When the app starts have him choose a google account and save the account ID (the email address) server side.
Also make sure the user can change the referenced account, it should not make any difference, as long as you allow just one account per user.
Ideally, as time passes by, you may want to track the active installations for each user, and limit the number of devices (model name, IMEI if available, OS version etc) to prevent fake account sharing. But that's something you can do later.