I'm using firebase authentication for my app and I have the users sign up, login, and log out all set up and going. However, I'm a little confused on how to manage the state of the users login status. Currently, if a user is logged into the app, but doesn't use the app for an extended period of time, firebase doesn't recognize them as logged in. I'm looking at the documentation and the approach is a bit unclear.
Should I be storing a FIRAuthCredential every time the user logs in, and then call reauthenticateWithCredential using that credential?
Firebase Auth only requires recent sign-in for sensitive operations like: deleting a user, changing a user's email or password. These are for obvious reasons. You want to make sure it is the same user before making such sensitive changes. Otherwise, the user is considered signed in indefinitely by the Firebase Auth backend (your assumption that "firebase doesn't recognize them as logged in" is not correct). Of course, a developer may also require re-auth before other operations like updating credit card, shipping address, etc. A developer would check the auth_time on the Firebase ID token. Only in such cases would you re-auth. You should never store credentials such as password on the client to avoid prompting the user to reauthenticate. It is needed to protect the user's account.
yes I think that is going to be right approach or second approach you can try is like when a user press login button instead of directly calling Authenticate User put a check in which last login timestamp value will be stored when user login compare timestamp value and then perform selected operation as you want . NOTE - you will be required to check weather user exist or not , but I think first approach will be better as if you had noticed in many Social apps like kik it ask for reauthentication after a long period of time but first it authenticate user instead of displaying home screen it take to reAuthenticate screen
Related
I have used Google Sign In to authenticate users with Firebase Auth, and I successfully get back my Firebase User. I want to keep the user authenticated, when they come back to the app. How can I do the same?
Users already stay authenticated. After you restart the app, Firebase reads the credentials from disk, and refreshes the user's token. Since this requires a roundtrip to the server, it happens asynchronously. So be sure to await _auth.currentUser() to get notified of the user's status.
Whenever I'm wondering how to do such things, I look at the FlutterFire sample app. This specific line can be found here.
Yes you need to do the auth.currentUser() function in order to keep users authenticated and the best part is that this function will work even if the user is offline, which makes it very versatile.
I want to offer some paid content in the app but I don't want the user to go through an Authentication process. I would like him to enter the app and directly be able to buy some of the content and remember that this user has bought it if he comes back later or uninstall/reinstall the app later on. (Like most meditation app on the Store right now)
Is it possible using Firebase Services and if so, what would be the good way to track paid content for anonymous user?
An Anonymous user IS a user without details (Name, email, password, etc). It has a unique UserID
So YES. You can save anything to the database using the User's unique ID. But remember. Every app is capable of performing operations inside their sandbox directory. which also has a unique ID and resets when the app is uninstalled.
In a sentece. Firebase won't remember the Anonymous user ID if the app was deleted intentionally.
The docs does state this very well:
You can use Firebase Authentication to create and use temporary
anonymous accounts to authenticate with Firebase. These temporary
anonymous accounts can be used to allow users who haven't yet signed
up to your app to work with data protected by security rules. If an
anonymous user decides to sign up to your app, you can link their
sign-in credentials to the anonymous account so that they can continue
to work with their protected data in future sessions.
Read more:
Authenticate with Firebase Anonymously on iOS
You could theoretically set it up to where it would redirect the user to a TextField page asking him/her to make a "password" and "PIN" of sorts. This "password" and "PIN" could then be stored into a SQL server database as an anonymous user. When re-downloading the app you could have a page dedicated to purchase recovery where all a user would need to do is input this "password" and "PIN", after they have correctly entered both it would return purchases to their account.
things to be wary of:
-People may use the same password, which is why I recommended a PIN as a way of two-step authentication. Keep in mind also that your app will need to test the password against the server before uploading to make sure that the password doesn't already exist and tells the user that the password cannot be used in such case.
-This is essentially the same thing as an account with a username and password... the only difference is that you aren't going to be collecting other information on them, such as email and birthday, etc., making it more anonymous.
-This is a very rare case of question and I know this is a crappy answer, but honestly this isn't the best idea to implement unless your app heavily relies on it.
I cant find any help around on this topic because I am being told how to implement it rather than how it actually works.
All I know is two-factor authentication is authenticating users through an email and a phone number.
Here are my set of questions :
Does it authenticate users by verifying their email and phone number at the time of registration?
Does it authenticate users by verifying their email and phone number on every login?
Why is it that every user can set two-factor authentication enabled or disabled for their account? Isn't this an admin thing which should not be decided by the user?
I'll see if I can help clarify for you.
It works as an extra level of security. Traditionally you would have a username/email and password to get into a site. If the password is compromised then so is the account. Adding a phone number to your account will mean that only someone with access to that phone can get past the extra level of security and access your data.
When the user logs in with another 'step' is added before they get through. A token (usually a number with a short expiry - i.e. seconds) is tied to the user logging in and sent to their phone. They fill in the form and submit. The device the user is logging in with (laptop/phone/desktop browser) can then be tied to their account (see point 2 below).
This can be the case but if you take Google as an example you can select to 'Trust' the device logging in for 30 days. This ties the device to a trusted list (perhaps stored in a database for instance) for a set amount of time before asking at the point of login again.
Common practice is that it is the user's choice as to whether they have this extra level of security. They may not have access to a phone...what happens then? They may like the convenience of just using a username/email and strong password....it doesn't mean to say you can't force it by design in your system though.
Context
I am using Parse.com as my backend for a mobile app. I use Facebook login only for now.
Assuming the user has logged in with Facebook and now has an account created on Parse already.
Question
Every time the user opens the app, should I do a check if his account is still valid by using PFUser.currentUser().become()? Or should I use the cached PFUser.currentUser()?
I have found out that if I delete the user account in the Parse backend, if I don't do a become(), the PFUser.currentUser() is still valid, even if the account does not exist anymore.
What is the best practice?
It's generally better to add a column to the user such as 'disabled', and when the app starts you can refresh the user, check that flag and display a message to the user and logout. That, from a user point of view, is similar to using become (at least as long as you check and notify the user).
So, you should do something if you're going to be removing or disabling users in the background. The main question is wether you fully delete the account or just delete the contents but leave the (empty) user in the system as a record.
I'm currently implementing an Oauth consumer service which is going to use Soundcloud as an Oauth service provider as well. But I'm having the following issue with it: Taking Facebook or Twitter example, you go there, you sign in, you fill up the permission form, and you are redirected back to your app. If you go there a second time, and given you are already sign in, you basically skip all steps and are redirected back instantly. That means, Facebook recognized that you already gave permission to that 3rd party service, so it doesn't ask your permission constantly.
And that's what's happening when I use Soundcloud. Basically everytime I redirected the user to the Soundcloud Oauth connect endpoint, the permission form always shows up, even though I already gave permission to that 3rd party service previously. I'm forced to press "connect" every single time, which is a drag from the user perspective (how many times can you give permission to the same entity). My question is: is there a parameter I can use to make soundcloud recognize/validate the previous permission from the user account to that specific 3rd party service? Or is this Soundcloud Oauth design implementation and we have to live with it?
Edit:
Maybe this wasn't clear, but each time I press "connect" in soundcloud, a new access token is being generated and delivered. Since my app uses this access token to identify its users, it doesn't work very well for me that the access token is getting updated everytime I want to log in, making me effectively "sign up" everytime. To sum it up, I want to get the previously attributed token to my account, so I can look up in my database, identify it and log him in.
I'm also looking for a solution which doesn't involve storing state in the client that might get cleaned up.
What you can do is store the user's oauth token in local storage and reuse it in future sessions. That's what happens on soundcloud.com.
A longer explanation:
When you use the Connect flow, the user is authenticated by SoundCloud (either by using username/password, Facebook Connect, or an already-existing session on soundcloud.com), and then when it is successful, your app is given an oauth token for that user. This is passed to the callback page which is registered for your app.
That token is the only piece of information needed to have the user be "logged in". Unless the token expires (by time, or by the user manually revoking it), then you can reuse that in future sessions.
I think I'm a bit confused about your application's design: where and how is the oauth token being used? I think that instead of using the token as an identifier, perhaps the user's permalink might be better? If you have the oauth token, you can find out the permalink by querying api.soundcloud.com/me.