I was looking at the facebook tutorial here
I am having some generic questions about integration and data management of user profiles (slightly confused).
So let's forget the facebook API for a minute, upon normal sign up I use a database that I capture the user details like desired user name , password and email ,dob .
If I use the facebook api shall I write tjose details anyway on my db and create a random username / password for the user and associate it with the facebook name (create a new field) or it's best not to write any information on my db at all? And then they can just use fb every time that they need to login .
I guess fb login takes away the username and password completely and still provides me with some information e.g email , date of birth etc....
Basically you will need some way to differentiate between Facebook users and users that have logged in manually. They will pretty much share the same fields (you can even request the users DOB from Facebook).
In both scenarios, you'll want to have a record in your DB for the user. With regard to a unique identifier, you could easily use the user's Facebook ID. After the user has logged in, you should not differentiate between login methods.
Related
I have a website where the user can create an account, given the basic user information like "username", "password", "e-mail", etc...
Now, I want to implement google sign-in, but im not sure how the back-end will be managed.
Should I create a different table for google users, or merge it to the original user table, but the problem is the google sign-in has no password associated with it, do I make the password not required, generate a random password, or make the user create a password?
And what if the user wants to register through the regular means with the same e-mail, but it already used the google sign-in, should the account be merged with the original one so he doesn't loose his data?
what you are describing here is a problem that many websites have. I don't think that there is a right or a wrong answer.
From my experience:
I would suggest to maintain a column in your user table that indicates the auth type. it could be "password" for users who login with password, and "google" for login with google users.
the password column should only be populated when the user actually uses the password auth mechanism. That is for security purposes to ensure no account take overs happen on accounts that are authenticated via other means.
If you want to allow users to "login with password", then you can implement a flow, that will:
send a confirmation email to the user (so you know the person logged in has access to that mail account)
when the user clicks the link asks the user to specify a password
then save the password and update the authentication type.
Also - the other way around - when you have a user who has a password and then starts to click "login with google" - you should probably also have a flow to migrate the user to login with google.
I'm trying to use Firebase as an authorization method for a paid Shopify website theme. The idea is the store owner purchases and downloads the theme files, and after purchasing also creates a firebase account with an email and password. Then an API key for the theme will be emailed to them. Once they have the API key they will input their account email and API key into the settings within the theme files. To authenticate the user the theme files will have some javascript that checks if the username and password inputted correspond to a existing user in the firebase database. If the email and API key inputted does not match to any user in the database then the user will be redirected to an error message HTML file, or get an error message popup that they cannot close saying to input the correct key.
Another possibility is to use the firebase firestore unique user ID instead of generating user API keys. Maybe this way there would be no need for using the firestore database.
Either way, this logic seems ok if it was a single user. But since it is a website theme file it is possible that every users website will get thousands of customer visits per day. Thus every customer that visits the clients site will trigger an authentication check with firebase with the clients email and API. So every user account on Firebase could potentially have thousands or maybe even hundred of thousands of logins and database queries everyday (depending on how popular their website is). So this is the part Im worried about.
Anyone have similar experience using Firebase for website theme authentication? Perhaps I am going about it all wrong here. Or maybe Firebase is just the wrong tool for this job.
Appreciate any input!
I am building a login system that depends on Facebook login plugin (https://developers.facebook.com/docs/facebook-login/web). Everything is going well with this easy to use plugin. The bad news is that: today, I noted that the Facebook changes its user IDs, and these changes can deceive your login system.
Explaining the process and the problem:
1- The user goes to your website and click Facebook login button to access to your website.
2- The plugin grabs the user's information from Facebook API, including the user Facebook ID.
3- Your script uses the grabbed info to check your database, looking for the Facebook ID in the users table.
4- If the Facebook ID exists, the system allows the user to login. If it does not exist, the system creates a new account for the user and login him/her to your website.
So, the same Facebook user might be registered more than one time as long as the Facebook changes the user's ID.
As I noted today: Sometimes, the Facebook gives its user an ID with 9 digits, and other times give the user an ID with 19 digits. If you used any of those IDs; it would redirect you to the same user's profile. For example: if the user's IDs are 999999999 and 1010101010101010101
https://facebook.com/999999999 and https://facebook.com/1010101010101010101 both URLs will lead you to same profile.
P.S. The script checks with the user's email, however the user has the choice not to supply his/her email address to your website.
I use API v2.. I didn't use the old version (v1.). So, I think this is not the issue of chronicle or app scoped IDs.
If you have any ideas that help in getting a fixed Facebook user ID, please let me know.
Thank you in advance
I'd like to simplify the authentication workflow in my Firebase app, and let users connect without password:
With third party OAuth providers: Facebook, Google, etc.
or
With email
If the later, the user would just fill in their address, receive a URL, and instantly get logged in without having to type/remember a password.
Whenever they logout, or, their session times out, they would enter their email again, and receive a new link to start a new session.
How to do that with Firebase?
I feel like it's not possible on the client, so what would be the best server side routine to achieve that workflow?
Finally, after taking some time to figure this out, I quickly realised that the email verification process cannot be used to solve this: the function to get this email sent can only be called by already logged-in users (which makes perfect sense). Hence it cannot be used to sign-in.
I ended up using this workflow with Firebase custom authentication :
CLIENT User asks to login, he's asked his email address, and told he will receive a link to complete log in upon form submission.
SERVER Receives the email address. Finds or creates user id belonging to that user, creates a custom token with this uid and sends an authenticated link by email (for example: http://myapp.com/?token=XYZ)
CLIENT User comes back in the app by clicking on that link, and the app can use the token parameter to immediately log-in the user using firebase.auth().signInWithCustomToken(token).
Look, ma, no passwud!
For Email part you can :-
Use custom passwords from Front-End eg:- timestamp's or some random words+timeStamp . And store that timeStamp in the users's Database for future reference for session expiration.
For sending a link for starting a session you can use the verification email to send a link inside and modulate the contents of the mail as per your needs.
For knowing when your session expire's:-
Just retrieve the timeStamp lets say that is timeKeyRetrieved
Check how much time has passed since the timeStamp
PS:- For checking wether user session has expired during the user is online. You will have to use timer. And whenever your users gets online just retrieve the timeStamp in AppDelegate methods or viewWillAppear:
I'm looking into what it would take to add a feature to my site so this is a pretty naive question.
I'd like to be able to connect buyers and sellers via an email message once the buyer clicks "buy".
I can see how I could do this in java script, querying the user database and sending an email with both parties involved. What I'm wondering is if there's a better way I can do this, playing monkey in the middle so they only receive an email from my site, and the it's automatically forwarded to the other party. That way they don't have to remember to hit reply-all, just reply. Also their email addresses remain anonymous.
Again assuming I generate a unique subject line with the transaction ID I could apply some rules here to just automatically forward the email from one party to the other but is there an API or library which can already do this for you?
What you're describing would be handled largely by your backend. If this were my project, I would choose the following simple route:
Store the messages the buyers/sellers send in your own database, then simply send notification emails when messages are sent. Have them reply to each other on your own site, like Facebook and eBay do.
An example flow would go like this:
(Gather the user and buyer's email addresses via registration)
Buyer enters a message and clicks 'Send Message' button on seller's page
Form is posted (via AJAX or via POST) to a backend script
Your backend code generates an email message
Sets the 'To' field to the seller
Your seller gets an email alert of the potential buyer which shows the buyer's message
The Seller then logs on to your site (made easy by a URL in the email) to respond
The Seller enters a response message on your site and hits 'Reply'
Buyer gets an email notification with the message body and a link to your site where they can compose a reply.
...and so on. So, replies would have to be authored on-site, rather than as an email 'reply.'
If you choose to go this route, there are some simple 3rd party "transactional email" providers, which is the phrase you'd use to find them. I've personally used SendGrid and found them easy to set up and use. They have a simple plug in for every major framework. There is also Mandrill, which is newer but gets good reviews as well.