I'm thinking about using anonymous login in one of my apps as I don't really need to know anything about the user and using the account across devices is not required.
However, the user has to provide some information (once when first using the app) in order to use the app. This information is - obviously - linked to the user account. And of course the user should not have to enter this information more than once ever.
My question: What is the "lifetime" of the anonymous account? In which situation will there be a logout / creation of a new anonymous account?
E.g. after restarting the phone, will the user still be logged in with the same account as before the restart?
Thanks for your help!
PS: I only care about Android (and potentially also iOS) - but not web!
What is the "lifetime" of the anonymous account?
An anonymous user looses his account if the option to log-out is available or if the user uninstalls the app. So you can use Firebase anonymous aAuthentication to create and use only temporary anonymous accounts to authenticate with Firebase. As I said, anonymous authentication accounts do not persist across application uninstalls. When an application is uninstalled, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account. Unfortunatelly, there is no way to reclaim that token for the user.
If you need more details for your users, you should encourage them to fully log in with a supported account provider (Google, Fabcebook, Twitter and so on) so that they can log in from all their devices without worry of losing their data.
In which situation will there be a logout / creation of a new anonymous account?
Only if you want that user to create another anonymous account.
after restarting the phone, will the user still be logged in with the same account as before the restart?
Definetely!
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 have used Anonymous sign-in for my users. I want my users to be able to sign out if they want (by clicking on a button). Now, I want to delete the account when the user signs out. That's why, I want to use
FirebaseUser user = FirebaseAuth.getInstance().getCurrentUser();
user.delete();
But, in the Firebase documentation, it is mentioned that if a user is signed in for a long time, then we must reauthenticate the user before deleting, otherwise it may throw an exception. Now, the question arises, how can I reauthenticate an anonymous user? I am a beginner and this is my first project where I am using Firebase. My concepts maybe wrong. Please help.
The requirement to re-authenticate users before sensitive operations (such as deleting their account) only applies for providers that require the user to enter credentials. For anonymous users, there is no need to reauthenticate them before deleting their account.
I am using Firebase Unity. I found that in a separate run of the app if you initialize FirebaseApp with the same string name, you can get the previous run's FirebaseAuth's CurrentUser and I can see the UID. I can even preserve 2 CurrentUser by multiple FirebaseApp instance (seems to be linked by string name)
This way I can use SignInAnonymously in an intended way, to onboard the player and let him play as many days or as many app run as he wants until he want to commit to the game by providing e-mail and password for LinkWithCredentialAsync.
I also found that if you uninstall the app or clear app data in the Settings of Android, the auth is gone. But app updates preserve the auth. Understandable.
But what I worried is that can the preserved auth expires on its own? For example the player played the game last year with anonymous ID without committing to linking to e-mail credential. If he come back a year later can he still access the same account? (The app is not reinstalled, just upgraded.) I don't see any info in the docs about this.
I also found that if you uninstall the app or clear app data in the Settings of Android, the auth is gone.
That's correct. Firebase Anonymous Authentication accounts does not persist across application uninstalls. If you uninstall the application, everything that was saved locally will be deleted, including the anonymous auth token that identifies that account.
But what I worried is that can the preserved auth expires on its own?
Anonymous auth token that identifies a user account don't expire. Firebase doesn't remove the token automatically or in any other way because it doesn't really know if a user is still storing data linked to that anonymous account.
For example the player played the game last year with anonymous ID without committing to linking to e-mail credential. If he come back a year later can he still access the same account? (The app is not reinstalled, just upgraded.)
If the player did not uninstall the app and he also did not clear the cache then he will definetely be able to play again with the same account.
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.
I'm writing 1) an app that stores a username and password in the AccountManager, and 2) a separate background Service app that accesses those credentials to login to my servers, etc. Playing around with this, I find I'm able to call AccountManager.getPassword(account) from the Service (app 2) to access the type of accounts I've add to the AccountManager using the other app (app 1).
Due to this, I'm starting to wonder what stops an arbitrary malicious app from 1) including the fields in the manifest to have Account management access, and then then 2) from iterating through all accounts of a particular type and calling mAccountManger.getPassword(account) on them. I know that during installation, a dialog pops up with all the permissions that an app requests to use, but I don't think we can count on the average user to reject an app because it requests suspicious permissions.
Is there a way to prevent getPassword from being called on an account type? Are there ways to protect accounts in the AccountManager from apps that have given themselves lots of account permissions?
Account data protection is based on the Linux user id (UID) of the process making the request. (See Security and Permissions in the guide.) Each account is associated with an account authenticator (that has a UID), and the process calling getPassword (or several other methods) must have the same UID as the authenticator.