I think this may not be the right question for this forum, but I could not think of where else to post it.
However, here goes. I am creating a dating app in android. One of the major hurdles I am facing is user authentication and verification.
Put simply, how do I ensure that a user is who he/she really says he is? How do I prevent, or reduce people creating fake profiles on the app? One way to do this would be to force the user to connect with his facebook account, but again, fake facebook profiles can be created.
Is there any other good method to ensure user verification?
The best way I can think of, although not fool proof, would be when the user creates an account it sends them an email where they need to click a link. Clicking the link can ask for some confirmation of something, such as their chosen username and or the first name and last name etc. If they fill in this information from the email, they're probably legit and you can mark the account as active within the database. If after x number of days delete any accounts that have not been verified.
Related
Im working on a project where a user isn´t forced to sign up a account.
My plan is that a user could do anything like a user that is registered except for a few exceptions.
I implement a like function which saves the users behaviour on a webserver and later when the data is fetched again it recognized if the user liked something or not. My problem is that I have to save this informations also if the user isn´t registered to my application. A User should be free to decide wheter the user likes to sign up or not and isn´t forced to be a registered user.
I found three different way that could work!
1. Option
First option would be the accountmanager but I don´t like this option at all cause I have to ask for the contact permission and also ask which account a user want to use.
2. Option
A other option would be if a user starts the app for the very first time the app would call a server which creates a random unique code and send that code to my application to save it as key for the users actions which is saved on a server. But that also doesn´t seems to be a good solution for my problem.
3. Option
The last option would be oauth but for now I don´t know if and how it would be the solution to my problem!
I would be thankful for every answer!
I have worked on a comic app that requires saving the user subscribed channels, genre or comics and save the likes/dislikes for the same. User can be subscribed to push notification too.
For this, we used Firebase Authentication (anonymous signup). And to save the user subscription information, we used Firebase Firestore.
And followed the below approach.
As soon as the app opens, check if the user has already anonymous SignIn. If it hasn't, signUp silently.
Add a listener for user push notification token change. And update it to Firestore by anonymous user-id as key (We did same for storing other information too).
I think this approach would help to solve this problem.
You could use firebase auth for that!
Usually, you would use it with email & password or google login but it also has an anonymous login feature that should save the user's phone.
There are few techniques. It depends on whether you want to recognise a user between installations of app. If you are OK to lose a user on reinstallation you can use Firebase installation ID and link users behaviour with this id. If you want to remember users even between installations you can use unique to each combination of app-signing key, user, and device Secure.ANDROID_ID(more info about ids). But still the best way is implementing your own signing in or using of AccountManager.
I've been setting up in app billing the last couple of days and been trying to go the right way about it. The guides recommend using a secure back-end server to store the purchase token rather than storing the data locally. The documentation on verifying the purchases on a server is very thin and I'm not sure whether am going the right way about it.
I am using cloud fire store to store the purchase information mentioned in the title. I have a couple of questions:
Should I be reading my product id from a server rather than having it hard-coded in the apk?
How often should I/Do I need to read the device id in this case and search on the DB to make sure the user has a valid purchase? Just the once when making the purchase or intermittently?
If I am to do this, what happens when the buyer changes their phone? The device ID will be different and I wont have a record of their new device making a successful purchase. Or here do I query a skupurchase and it returns the item is already owned, write these new details to the DB?
and finally should I store a successful purchase flag in shared preferences or something so I am not constantly reading the DB and the user can use the device offline?
I was going to go down the route of getting users email using this answer here but there is a lot of comments saying this is very intrusive and I only need it for a simple thing. So I went the device ID route.
BTW I only have one product that unlocks full features and is non-consumable.
What is the correct way to go about this?
This was my approach to the same problems. It may not be relevant to your scenario. Hope it helps.
Should I be reading my product id from a server rather than having it
hard-coded in the apk?
You should store productIDs in the code as they will be used to provide features coded into the app.
How often should I/Do I need to read the device id?
You should not rely on the device id as you have raised the concern about the user changing the phone. You would want to implement the login system and make user login into the app before purchasing the product. This will make your subscription device independent.
The process should be:
User tries to use the locked feature.
App asks for login. Make user register and log in.
User clicks on the buy button again and completes the purchase.
Your server stores the user login information with the purchase information.
User changes the device.
User tries to use the locked feature.
App asks for login. User logs in.
The server returns purchase details with user info.
The app unlocks the feature.
How often should I check purchase details from the server?
You should check for purchase details intermittently.
Why? The user may ask for a refund after some time or the payment gateway would void the purchase for some reason.
IMO, there should be two types of sync methods silent and forced.
In my approach, silent sync would check for internet every 9 days. If the internet is not available, it would not do anything. While the forced sync would check for internet every 25 days from the last sync. If the internet is not available it would ask the user to turn it on otherwise, the user wouldn't be able to use the app.
I was using the subscription period of one month but as you have a non-consumable product you can afford 2-4 months forced sync period.
Should I store a successful purchase flag in shared preferences or
something so I am not constantly reading the DB and the user can use
the device offline?
The syncing process and the login would solve this problem.
I think you might be reluctant to implement a login system for such a small thing and think it would make fewer users buy your product. But by implementing Google authentication it would be fast and users would be less frustrated by it.
Implementing this approach involves a lot of server-side logic.
Im developing an android application for the first time (no prior experience whit coding....). Mainly the app is going to be used at work as a tool for service technicians. The app is almost ready for field testing, but there is one thing i need the app to do before that. I need the app to force the user to log in every time its opened. This is because some of the info on the app is confidential, and only people that currently works for the company is allowed to have this info. Whit firebase i can then block the users that leave the company, or users that are not verified. Currently the users sign in whit google and they stay signed in until they clear the app data or delete it.
I have looked far and wide for the answer to this, but i have only come across different use of timers.
If anyone has a better solution to this "safety" issue, im open to anything.
If you are using Google Sign-In for authentication, there is no out of the box support for forcing your user to authenticate with Google every time they use your app.
This makes sense, because the user is still authed with Google on your phone. A login system only authenticates the user; it doesn't inherently protect data stored on the device. As long as Google has a valid access token, the user won't have to type a username and password again (and simply clicking "login with Google" again doesn't really provide extra protection here).
If your primary concern is blocking access to users who have left the company, you should be covered if you are using Google Apps for your company. If you disable the user's account, their access tokens should become invalid. Google Apps admins can also manually revoke access to specific apps for specific users.
If you don't use Google Apps (e.g. your users are using #gmail.com accounts or accounts from a domain outside fo your control), you might want to consider implementing a list of users allowed to access the application, and verify the current user has access by checking that list via an API call on launch.
If the goal is really protecting the confidential information in the application, you might want to take an approach similar to Android Pay in which you require your user to set and enter a PIN number to access the application. As an added benefit, you can then use that PIN to encrypt any confidential data you are storing locally.
I will suggest you take a look into shared preferences and every time when the user is back into the app you send them to the login activity.
Hiho,
is there a solution to disable my App for one single user?
There is one Person, who buys my app every few days to use the app for calculations, and than deinstalls the app within the 15 Minuts window.
Over 10 times he did it and with the next update i want to create a method, that checks the user mail from market and if its these person, the App should close instantly.
Thanks for Help
Alex
Are you sure this is the same user (and not just a usage trend of one refund every few days)? A user should only be able to refund an app once. According to the App Refund article in Android Market Support:
You have 15 minutes from the time of download to return an application purchased through Android Market for a full refund. You may only return a given application once; if you subsequently purchase the same app again, you may not return it a second time.
EDIT: If it looks like it's the same user, please contact Android Market Support and let them know. Follow the relevant "Contact Us" link at the bottom, and include all relevant information: App name, user's email address, order ID's, etc. Abusing the refund policy like this shouldn't be possible. If it is, they need to know so that hole can be closed :)
you can get the accounts from accountmanager, as I know to do what you want, checking account is the only way I think. you will need GET_ACCOUNTS permission.
Instead of putting in hate code for this single user, I'd suggest you put in a little more effort and put in a more generic check.
Whenever a user signs up, check if the user has already used your application, and if he/she has not, save the user's account information on a backend. Else notify him saying that he/she has already checked the application out and if he/she has some feedback. Try to make the user 'guilty' here!
Building a backend system is pretty simple with a service like stackmob.com. Though for this, you'll need to acquire the GET_ACCOUNTS permission, and for a service like calculator, asking for this permission might seem fishy. So you need to make that call here!
If you do figure out how to identify your user rather than close right away you should do stuff that delays them for 15 minutes.
Make them fill out some forms first (Just for that user), stuff that takes time. Be really specific in the forms with password requirements like 10 chars including upper, lower number and punctuation, then force them to "Log in" using this password (which they won't remember and will have to start over...), but always make it look like each step is the "Last little bit" they will have to do before they can use the app...
Also use a lot of "Contacting server..." and "Calculating" and "Installing" that take time. If you really need to stretch it out, add a few "Retrying" after the connecting message has been there for a while.
I have an app that creates an account for a web app, which is basically sending and receiving SMS messages from the web. This is how it works (not released yet, nearing the end of the first-release features I had planned):
The user purchases the app.
The user enters their name, email, and password.
The account is created on the server-end, and the final view is shown telling the user where to access the web app.
The background processes are opened (C2DM and ContentObserver for SMS).
All goes well. The android part of this app all works flawlessly, but I'm scared of people making multiple accounts from one purchase. How could I stop this from happening? I am clueless when it comes to this subject. First of all, when the final view is shown, a user could just hit back and then recreate another account. How can I prevent them from going to that form ever again? I am thinking I can just set a SharedPreference, but then all the user has to do to make another account is uninstall the app and then reinstall it, and bam another account is made.
I need a way, so once the user registers for the first time, there is in no possible way they can register again, on that specific phone (or specific Google account). Is there any real way to accomplish this? Any help is appreciated, I am stuck when it comes to this topic.
Since SIM identification functions (getSimSerialNumber) return null on CDMA devices and *ANDROID_ID* is said to be the same value on CDMA devices; with addition of tablets which do not have either of them, I highly suggest implementing your own unique identifier in your database and matching it with user's Google Account.
However, since a poweruser can always reset their app data storage and clear their identification from device (thus making your app session on device brand new on app launch) this approach has it's caveats.
You may want to check this blogpost for ideas about generating your unique id
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
I would make it a check on the server side.
Every device has a unique identifier. If you save this on the webserver side during the account creation, you check whether or not an account has already been made on this device. Also add the same check for the Google ID, just in case.
String android_id = Secure.getString(getBaseContext().getContentResolver(),
Secure.ANDROID_ID);
Might be worth a try. Your safest bet will always be something on the server side, since the device side is easily tempered with if people really wanted to.