Is there a way to know if a newly created user was done so using the client or admin SDK?
No, the auth trigger isn't origin specific. It doesn't care how a new user account gets created... it doesn't get called/triggered until the creation occurs.
Not to go too far off topic from your question, or turn this into a fully-fledged conversation, but what are you trying to accomplish that you want to detect what created the account? I feel like there's probably a different way to handle the scenario you're facing.
Related
I am working on a simple app that allows users to search for something using an API and save it to view later.
However, I don't want to integrate authentication in the app. I can, but would rather not as a UX decision. Do you know of a way to generate a device token, that is unique to every device and can be used to store which assets a device has saved in the db?
I am thinking of expo push tokens as a possible solution, but that would require users to accept push notifications - so what happens if a user says no?
Sounds like you could just use react-native-uid to generate a unique id for your device and then store it in AsyncStorage and fetch it from there going forward.
For more inspiration, or perhaps just a more canonical way to do this... read up on suggestions surroundings the recently deprecated constant for installationId here:
https://docs.expo.dev/versions/latest/sdk/constants
I haven't used this before but if you're looking for something bullet proof then this is probably your goal of getting the same concept.
Firebase Anonymous Authentication might be ideal to use in this case. This can be used to create a user in Firebase auth without any credentials and can be useful especially when you are using either of Firebase's databases since you can use security rules with user's UIDs.
However, once the user logs out of the account by any means including but not limited to using sign out option in your app, clearing app data or uninstalling the app, the same account with that UID cannot be recovered. I looked up for AsyncStorage and apparently that gets cleared to if the app is deleted.
I'm new to react native. I am trying to develop an application that uses firebase user authentication. But there is something I can think of. For example, 2 users have registered to my application but I want to show extra information to the first user according to a condition.
How can I separate these two?
Where exactly should I manage this condition?
The question is not super clear as to what issue you are trying to tackle so I apologize if I am inferring incorrectly.
I use MongoDB personally with a Node/Express backend for user data and haven't used Firebase myself but I'm sure you can do the same things with it. I'll be speaking in Mongo terminology but again I'm sure you can do the same with Firebase and at the least this will give a good idea of the thought process.
I have a UserSchema that holds all the user information. When logged in the client app would get this information to be used on the frontend after authentication.
Assuming you are only displaying "extra" information that doesn't need additional privilege you can just pull in the users data stored in firebase and handle the display of this extra info with logic on your frontend client.
If its extra privilege you need to setup firebase to look at the user data that is authenticating and only serve back information if they have the proper privileges.
Also important to note, you should ensure that when you are updating user information from client -> firebase backend you should ensure that you can only update specific user fields via read/write authentication on firebase.
Hope this gives a little better idea on how this process might look. I'll let someone who has used firebase specifically add tech specifics.
(this was originally a post on the flutter-dev reddit that was redirected here)
So I started making this flutter app using firebase as a backend and after looking at all the options for state management I finally realised that the tools provided by firebase already handle pretty much everything I would need state management for.
For example:
I could set the currently logged in user in my state to show the right login or home page and make the user uid available to widgets for their firestore API calls.
OR
I can just listen to FirebaseAuth.instance.onAuthStateChanged to show the right page and just use FirebaseAuth.instance.currentUser() from anywhere to get the logged in user uid and do my firestore calls.
What I mean is, for every thing that would require global state, I can just basically have a firebase stream listener.
Is this right ? Or am I missing something here ?
You're not missing anything. Since most Firebase APIs rely on data from Google's servers, many of them are designed to be used in a reactive way. Making your UI reactively respond to those asynchronous changes is (in my experience) the best way to keep your code simple.
There may be slight behavior between the different types of listeners. But the onAuthStateChanged listener immediately fires with the current state when you attach it, which makes it a good example of a listener that you can use everywhere you need to respond to auth state (instead of also storing that state somewhere in your app).
In that scenario I would say yes, you can read the onAuthStateChanged stream and react to changes. But there are also scenarios where I need a stream for interacting between widgets without a parent/child relationship. For example, in one of my apps I have a company selector, and the rest of the app reflects to the selected company. I created a stream, so that the company selector doesn't need to be a parent of the other widgets, and especially so that I don't need to pass the company parameter to all the widget tree.
I also have one scenario where I need to load extra information about the user that isn't available on the FirebaseUser object. So when the user is logged on I load their information from a "users" collection and then I add that to a custom stream.
So to conclude I would say yes, you should use the default Firebase streams when possible, but that doesn't mean you can or should use that solution for everything.
I'm trying to write a function that will check to see if an email is registered with my Firebase app (with Javascript/Web), before proceeding with the sign up process (if the email isn't registered).
I created a node named active_emails which I wanted to populate with registered emails (like an array). I was going to check the email against this list and if it didn't exist then I would allow the user to proceed with the registration process.
I see from the answer here: Proper way to store values array-like in Firebase that Firebase creates keys inside the array. So a normal Javascript array check won't work. I understand how the answer above works, but I was wondering, since I'm essentially doing a look up on the emails of registered Firebase users, is there another way to do this check?
Am I correct in thinking that the answer above requires Firebase to compile and then send an array of emails back to the user client-side? This seems like it might affect performance (if there are hundreds of thousands, or millions of emails on file), and would it expose all user emails to the client? Is there another way to check if a user is registered or not, maybe something like attempting a registration and then catching a duplicate email error (although this sounds like a messy way to go about this).
The top answer here: How to find out if an email is already registered with Firebase Simple Login? suggests using fetchProvidersForEmail as a way of checking to see if an email is registered, but that answer is for android and I don't know if it's possible to do such a thing with Javascript/Web.
I've tried to integrate this method here:
function checkEmail(){
firebase.database().ref().fetchProvidersForEmail("emailaddress#gmail.com").once("value", function(snapshot) {
console.log(snapshot);
});
}
But it shows the error: firebase.database(...).ref(...).fetchProvidersForEmail is not a function. Does anybody have any ideas on the best way to go about achieving this check?
Thank you in advance!
This method is for auth only:
firebase.auth().fetchProvidersForEmail("emailaddress#gmail.com")
This is deprecated.
firebase.auth().fetchProvidersForEmail("emailaddress#gmail.com")
Use this.
firebase.auth().fetchSignInMethodsForEmail(email)
So I'm building out an app with Meteor and noticed when I log in with Twitter and then Facebook, I create two separate user accounts. Is there any built in way to make sure these are merged? I'm not seeing any email address in the twitter based user account, so I can see it might be difficult to figure out which accounts to link.
Suggestions? Thanks!
I've been in a similar situation so here's a good starting point for you:
You might want to do the merge at the Accounts.onCreateUser event. Basically, what you would do at this time is to:
Do a mandatory protocol / routine to save the email in some profile field in any authentication method as much as possible, so that you are able to do the next step, which is..
Whenever another authentication method is used (to create the user), you can compare the existing database of users (now confident that an email field would be present at all times to check against), and do the merge whenever an exact email match happens.
It's a shame I do not have the code now because I tried this protocol once, but I quickly decided that I'll just stick with one authentication method for some reason. Maybe I'll update this answer when I can get around to try and code that again.. or maybe not.