I am on the edge to if I should try Firebase for my upcoming project, or stick with the good old SQL db. I have read through the docs, and I think I understand their deal, but there is one thing that's not clear to me; where is the user signed in?
Say I have a sign in page located at:
mywebsite.com/login.html
After the user has successfully logged in, I wish to redirect the user to the main panel which may be:
mywebsite.com/main.html
When the user is redirected, is he still signed in, and when does the authentication end? Thanks!
The user will stay signed in across page transitions. The information is retained in local storage of your browser.
The user will stay signed in until you sign them out explicitly, or until an even occurs that requires them to re-authenticate (such as trying to change their password).
Related
How do I make it so that when a new user signs up in firebase, they can only login with that provider? Ex: a new user uses an email and password to sign up and then is rejected when trying to log in with Google.
I'm using Firebase with javascript in React if it helps.
What you're asking doesn't sound possible. The different auth providers don't know about each others' user bases. jackoboy on Google isn't at all related to jackoboy on Facebook. While they might have the same email address, that's never a guarantee that they are the same individual. So when jackoboy signs up with Google, there is nothing that can possibly stop jackoboy from also signing up with Facebook as a different account.
If you want to impose your own checks to see if the end user might be the same, you're going to have to write some code for that on a backend you control, then delete the second account if it appears to be the same person, by whatever logic you determine. Firebase Auth just isn't going to do that for you.
We login users anonymously in our app using FirebaseAuth, and allow them a read-only access to some of our content. At a later point of time the user can decide to login with credentials and have access to more stuff and write user specific data. The question is, do we gain anything by linking the anonymous user with the one with credentials?
Since we do not have any user specific data when the user is anonymous, it looks like a performance overhead (linking and merging seem to be slower) to link/merge as opposed to a plain sign in. Is there a downside to not linking in this scenario?
You will end up with a lot of stale/abandoned anonymous user accounts and if you are saving anonymous user keyed data in your database, that will also need to be cleaned up if you choose to sign in instead of linking.
In that case (sign in instead of linking), you should consider deleting that anonymous user's data.
If you decide the linking flow, you will not run into the above.
On our app we are using "One account per email address". We want users to sign up using a specific authentication provider, which we keep track of, and stick with it.
What I've noticed today is that if I log in using a Google or Facebook provider I can then send myself a password reset link to the associated email address, which allows me to use the email/password provider instead.
There is a slight difference in behaviour depending on the first provider:
If I use Google first, after I use the password reset link I can now user either provider to log in, and both are linked to the same firebase uid. If I debug, I can see both in the providerDetails array on the authData object I get back from Firebase.
If I use Facebook first, after I use the password link the password provider replaces the Facebook one completely, although it retains the old firebase uid. At this point I can no longer use the Facebook login.
My questions are: is this behaviour intended, and, is there any way to switch it off?
This can cause confusion if say a user logs in using Facebook (which we track) and then later forgets and sends a password reset. It isn't the end of the world because they can carry on using the password login, but it certainly muddies the water.
Thanks
The behavior is intentional.
For end users, if they had signed into the app using Google or Facebook, and later they want to recover the password, the most likely reason is they (or an attacker) can not login with that identity provider.
After the user clicks the password reset link, Firebase removes the non-email identity providers to prevent other people from accessing the account silently. If the user still wants to add Facebook/Twitter login, they can do that via manual account linking (if the app supports).
In case the user's email service is the same as identity provider (e.g. #gmail.com users login into the app using Google), Firebase has an optimization to keep the identity provider since there is no security risk.
I have created an Appcelerator iPhone app based on Firebase authentication, which works very well. But now I come across some unexpected behaviour.
My setup is as follows: on app start, the user must login or register. During registration, the account is created, and the corresponding account data (uid, name, email, date etc.) is also stored in a /users/uid data entry.
When I remove a user from Firebase through the Dashboard, by removing it from both /users/uid and the "Login & Auth" tab, it looks all clear. But when the user opens the app, he still remains logged in.
How can I enforce removing a user, where he is also logged out the next time he opens the app?
According to the Firebase Google Group, this is a known bug with Firebase:
This is a known bug on our end. As you noted, after deleting a user,
existing auth tokens are still valid and can be used to read and write
to your Firebase database. Security Rules are still enforced on these
tokens and that user will still only be able to access their own
Firebase data (if your rules are set up as such). Those auth tokens
will be valid until they expire. There is currently no workaround for
this bug although we are going to be fixing this in a future release.
https://groups.google.com/d/msg/firebase-talk/Yr_wn02q0bk/eTM9hop3paoJ
The only thing I can think to do is check whether you can read to your users area, and if there's nothing there, force a log out.
From your behavior it seems like there maybe a configuration issue or just a bug. Does the users information get removed from corresponding data-source (DB or in-memory store)? I would start there then move on to researching how the corresponding cookies/tokens work and contact their support.
Though perhaps you shouldn't out right delete the user, perhaps just disable the user therefore, accomplishing the same result? Maybe this behavior will work properly.
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/