I'm using FireAuth to sign up my users, but i'm not using FireCloud (because we use our own back-end cloud database), and I would like to know if when a user connect with Google Sign In, if it is the first time or not he connect (to know if it create the user an account or simply log into one).
I've found this on the documentation of Firebase, it look perfect, but it's in beta and I don't seem to find the correct method with the dart package.
https://firebase.google.com/docs/functions/auth-events
Hope you can help me !
Thanks you for reading !
You can use isNewUser, which will return if the user is logging in for the first time:
AuthResult user = await auth.signInWithCredential(credential);
print(user.additionalUserInfo.isNewUser);
https://github.com/FirebaseExtended/flutterfire/blob/master/packages/firebase_auth/firebase_auth/lib/src/additional_user_info.dart
Related
I'm trying to get the UID of the user authenticated by firebase web sdk, in the cloud function. The cloud function is triggered by onWrite event of cloud firestore.
This function is triggered when the logged in user is creating/updating items to the cafe. The authentication is handled by Firebase Auth. The security rules enable write only for logged in users. So this event could be tied to a user.
export const cfun = functions.firestore.document('cafes/{cafeId}/items/{itemId}').onWrite(async event => {
// trying to get the uid here
})
There are examples in the docs that deals with the userId, but in all those cases the userId is part of the document path. But in this model the user is not part of the path, as a cafe could have multiple owners and so could be manipulated by many users. So adding userId to the path is not an option.
It looks like a common case for serverless architecture.
#
Update: Functions triggered by firestore doesn't have event.auth populated. Looking for suggestions on modelling the following requirement.
In the data-model, I've got cafes and owners. Each cafe could be owned by many owners and a cafe could be transferred to some-other owner at a later stage. So the cafes are modelled as /cafes/{cafeId} and everything that belongs to the cafe as /cafes/{cafeId}/items/{itemId} etc.
We also need to query cafes based on different params, if modelled below users it becomes difficult. For these reasons the cafe cannot be modelled as /users/{userId}/cafes/{cafeId}.
As far as security rules are concerned, I could control write access using get(<>) to determine who gets write access to cafes. There is no problem with the security.
I feel that the execution context should provide all available information and let the developers handle it appropriate for their use case. And for serverless apps userId is a must.
If event.auth is not provided in the function, then this restriction will force items that does not belong to users to be modelled /users/{userId}/<item_name>/{itemId} just for the sake of accessing the userId in the cloud functions. This doesn't feel natural.
Also right now there is no way to figure if the cloud function is triggered because of the changes performed in the console. The event.auth info that is available for firebase database triggered functions will be perfect to handle all cases.
Any suggestions regarding how to remodel this case is appreciated as well.
#
Thanks in advance,
I have been facing a similar issue. In Firebase, it was easy - you simply took the data from event.auth. I would assume this is simply a feature not implemented yet while we are in the beta phase of Firestore. Adding the user id to the path does not work as you previously mentioned as it will constantly be changing depending on the user making the update.
My scenario is that I want to create a "lastUpdatedBy" field in the object being updated. If we were to allow the client to send in a lastUpdatedBy field in the payload, this could be abused by a rogue client (i.e. someone with a authenticated account) trying to impersonate someone else. Therefore in Firebase we relied on a cloud function to populate this field on data change events.
My workaround is to allow the client to insert the "lastUpdatedBy" field but additionally use the Firestore rules to validate that the userId in the payload matches that of the logged in user - otherwise deny the write request.
Something like:
match /collectionA/{docId} {
allow update: if request.resource.data.lastUpdatedBy == request.auth.uid;
}
Until Google/Firestore guys add the "auth" object to the cloud function I don't see any other workaround but would love to hear differently.
Since Cloud Functions 1.0 you can get the UID like this
exports.dbCreate = functions.database.ref('/path').onCreate((snap, context) => {
const uid = context.auth.uid;
const authVar = context.auth;
});
Here is a nice post from the FB team for all CF1.0 changes: https://firebase.google.com/docs/functions/beta-v1-diff#event_parameter_split_into_data_and_context
The data of context.auth can be found here: https://firebase.google.com/docs/firestore/reference/security/#properties
I am developing a Flutter App and want to use Firebase Auth for user login. My problem is that I want to first ask for the email, check that the format is valid, and then send the user to a LogIn screen or SignIn screen depending on whether the email already exists on Firebase.
I read this question where it says that the only solution is to perform a signIn with createUserWithEmailAndPassword() method and check the error message, a solution that in the long term is not very reliable.
As flutter is evolving very fast, do you guys know of a better solution to accomplish this?
Thanks in advance!
I think you could also create a cloud function to make that check in the server, that would be an alternative method. The question stated a restriction about making the check within the app.
As regarding making the check using the error message, that was already fixed and now you can check it using the error code. (I updated my answer)
As you are signing up means mostly you will save user's data like profile name or something. While signing up new user save user's email into firestore if it's first time. Then from next time run a query whether email is present in firestore or not, which implies whether user is already authenticated or not (first time or already created account). If no document found with that corresponding email means user is new guy , you can sign in. If document found with corresponding email then login user instead of sign up.
I am struggling with the docs for Firebase, Google Cloud etc. I notice I often get stuck on this notation. There must be something I do not know about it or have forgotten.
For example this page admin.auth.UserInfo tells me I can get info about the user (email etc). But after reading the page I still don't know how. What am I missing?
PS: I believe I know that admin comes from this but it does not help me:
const admin = require("firebase-admin");
When using the Admin SDK, to get information about a user, call admin.auth().getUser(uid). An example is provided in the documentation.
getUser() returns a UserRecord. It contains an number of properties, including providerData, which is an array of UserInfo.
Each client SDK provides methods to obtain the UID of an authorized user. For example, on Android it's FirebaseAuth.getInstance().getCurrentUser().getUid() (example here).
The UID of each user for a project is available in the Authorization panel of the Firebase Console.
In your example you are reading the documentation of an interface. It defines what UserInfo has.
If you want to access to a method, for example for reading userInfo, first you have to access to auth service using admin.auth().<method>.
If you want more info about how to use it, see https://firebase.google.com/docs/reference/admin/node/admin.auth.Auth
I'm trying to get the UID of the user authenticated by firebase web sdk, in the cloud function. The cloud function is triggered by onWrite event of cloud firestore.
This function is triggered when the logged in user is creating/updating items to the cafe. The authentication is handled by Firebase Auth. The security rules enable write only for logged in users. So this event could be tied to a user.
export const cfun = functions.firestore.document('cafes/{cafeId}/items/{itemId}').onWrite(async event => {
// trying to get the uid here
})
There are examples in the docs that deals with the userId, but in all those cases the userId is part of the document path. But in this model the user is not part of the path, as a cafe could have multiple owners and so could be manipulated by many users. So adding userId to the path is not an option.
It looks like a common case for serverless architecture.
#
Update: Functions triggered by firestore doesn't have event.auth populated. Looking for suggestions on modelling the following requirement.
In the data-model, I've got cafes and owners. Each cafe could be owned by many owners and a cafe could be transferred to some-other owner at a later stage. So the cafes are modelled as /cafes/{cafeId} and everything that belongs to the cafe as /cafes/{cafeId}/items/{itemId} etc.
We also need to query cafes based on different params, if modelled below users it becomes difficult. For these reasons the cafe cannot be modelled as /users/{userId}/cafes/{cafeId}.
As far as security rules are concerned, I could control write access using get(<>) to determine who gets write access to cafes. There is no problem with the security.
I feel that the execution context should provide all available information and let the developers handle it appropriate for their use case. And for serverless apps userId is a must.
If event.auth is not provided in the function, then this restriction will force items that does not belong to users to be modelled /users/{userId}/<item_name>/{itemId} just for the sake of accessing the userId in the cloud functions. This doesn't feel natural.
Also right now there is no way to figure if the cloud function is triggered because of the changes performed in the console. The event.auth info that is available for firebase database triggered functions will be perfect to handle all cases.
Any suggestions regarding how to remodel this case is appreciated as well.
#
Thanks in advance,
I have been facing a similar issue. In Firebase, it was easy - you simply took the data from event.auth. I would assume this is simply a feature not implemented yet while we are in the beta phase of Firestore. Adding the user id to the path does not work as you previously mentioned as it will constantly be changing depending on the user making the update.
My scenario is that I want to create a "lastUpdatedBy" field in the object being updated. If we were to allow the client to send in a lastUpdatedBy field in the payload, this could be abused by a rogue client (i.e. someone with a authenticated account) trying to impersonate someone else. Therefore in Firebase we relied on a cloud function to populate this field on data change events.
My workaround is to allow the client to insert the "lastUpdatedBy" field but additionally use the Firestore rules to validate that the userId in the payload matches that of the logged in user - otherwise deny the write request.
Something like:
match /collectionA/{docId} {
allow update: if request.resource.data.lastUpdatedBy == request.auth.uid;
}
Until Google/Firestore guys add the "auth" object to the cloud function I don't see any other workaround but would love to hear differently.
Since Cloud Functions 1.0 you can get the UID like this
exports.dbCreate = functions.database.ref('/path').onCreate((snap, context) => {
const uid = context.auth.uid;
const authVar = context.auth;
});
Here is a nice post from the FB team for all CF1.0 changes: https://firebase.google.com/docs/functions/beta-v1-diff#event_parameter_split_into_data_and_context
The data of context.auth can be found here: https://firebase.google.com/docs/firestore/reference/security/#properties
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)