I have an app that allows users to only log in through Facebook. The backend is Parse. I have many fake users creating accounts and screwing up my app, posting inappropriate things. Is there a way to block a list of Facebook accounts from logging in/using my app? I have the list of their Facebook IDs, but I am not sure how to block them by writing a Cloud Code.
Thank you in advance!
Simply add a new boolean column to your User table to indicate if this user is blocked/blacklisted. Every time a Facebook user gets a new session, their authData field needs to be updated. So you can use thebeforeSave trigger on Cloud to check if a user is blacklisted and return an error which prevents them from getting a new token and logging in at all.
Now to block a user, find their session record in the Session table and delete it which invalidates their token and logs them out. Then simply set their blocked field to true. They should not be able to log in to your app any more.
Related
What would be the easiest way to have a contact form implemented into an Xcode ios app, where the user inputs their email, name and some hidden variables from within the program?
I'm thinking a firebase service will work well, as I don't want to use the built-in email form.
The contact form also needs to know if the form was submitted successfully, such as if the internet was out, or the server/service couldn't be reached. Any help or useful links would be greatly appreciated.
Firebase Authentication is great, it allows you to sign up/sign in users, so you can store them safely there.
Auth.auth().createUser / Auth.auth().signIn
The first method will create an auth user and returns you an uid key for that user, so you can use their Database to store anything related to that user using that uid. The second method will login an user and returns the current user logged in uid, so you can manipulate your data. You can make sure they worked by using the completion and checking if error is == nil.
I highly recommend you to use Auth to authenticate them, otherwise you would have to store their emails and passwords on your Database, and you would have to encrypt them.
Check their documentation here: https://firebase.google.com/docs/auth/ios/start
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
I've been looking around the web and trying to find out how to handle the user state of a logged in Firebase user where the following occurs:
User is already logged into the app.
Admin disable/delete the user from the Firebase Console.
User is still inside the app (although the account has been disabled/deleted on the Firebase Console).
After more than an hour, user is still inside the app. (Firebase ID token should have expired and addStateDidChangeListener() should've been called).
Currently, unless i call getIDTokenForcingRefresh() and signout() the user if the return error is due to disable/delete user. The user will still be logged in.
In summary, I've the following questions:
If a user is logged into the app, the user will remain logged in unless a signout() is called. It doesn't matter if the user account is disabled or deleted?
The Firebase ID token 1hour expiry only triggers the addStateDidChangeListener() but I'll have to handle what to do inside the handler?
What is the difference if I use reauthenticateWithCredential() to check for update state of the user?
Thanks for any clarification and help in advance! =)
I don't know if I will answer all of you questions but I can give you some info from my experience with Firebase.
As far as I know, if user gets deleted or disabled he will still be logged in app until token expires. Anytime you will try to manipulate with some data in Firebase (read, write, whatever) after the user has been disabled / deleted you will get an error in the result block. That is when you should check what kind of error it is and perform some actions. In this case, if error matched deleted / disabled user you should log him out and take to login screen. Here is a list of all errors.
reauthenticateWithCredential() is a way to do that but you will get the same error when reading other data from Firebase. So if a user is disabled, calling reauthenticateWithCredential() will return an error with code FIRAuthErrorCodeUserDisabled. That is how you detect that user was disabled.
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.
This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.