I have upgraded a Firebase app to the new version, so I see my Firebase at console.firebase.google.com.
The console shows me a message Wow, you have a lot of users! Because you have over 500 users, they aren't automatically displayed. The only way to see any user details at all seems to be to search for a complete email address and that only works for users with a password.
I don't know how I came to have so many users, it's a development system and I am not aware of more than a dozen userIds. Regardless, I would like to delete them all.
I get the same message in a production system which also has less than 500 known users, so I must have some that are not real - I want to be able to view some details and delete them one by one.
The Docs don't provide a solution for either requirement. Any suggestions please?
Related
I have some code I put in my react-native app a couple of years ago to support the forced migration of users from v2 -> v3 authentication. I am using the Web version of Firebase (6.6.0) in my app (NOT react-native-firebase).
I recently had a user try to log in with an old v2 token found in AsyncStorage (local storage). The app crashed with the following error:
TypeError · undefined is not a constructor (evaluating 'new t.default.Promise')
The crash occured on this line of the migration code supplied by Firebase. I'm guessing this migration code is no longer supported and I should just remove it from my app. But what should I do instead if a person tries to log in with a saved V2 auth token? Can she simply log out and log in again? Or does she have to change her password? Or does she have to create a new account, losing her old data?.
I don't have a way to replicate this situation since I have no way of logging in to v2 authentication. So I would appreciate a clarification from the Firebase team. Thanks.
TLDR; I've decided to remove the migration code from my app. When someone fires up the app and a legacy token is loaded from AsyncStorage, I simply delete the token and present the user with a login page.
I corresponded with Firebase auth support and include their answers below. First off, they suggested changing firebase.Promise in the code to Promise as firebase.Promise doesn't exist any more. This fixed the crash. Then, to test, I found an old simulator image that still had a legacy token in its AsyncStorage. Working with that, I found that the response to the XMLHttpRequest to the exchangeToken endpoint result in a null response (after approximately one minute). This tells me the endpoint is dead and there is no point in trying to query it, thus it makes sense to remove the migration code altogether from my app (even if the endpoint were working, a 2-year-old token surely would have expired.)
Then the question is what to do to enable users in this situation to upgrade gracefully. Firebase support suggested I should export the user (I have quite a few but I don't have a way to identify them definitively), then delete the user and import again. I couldn't believe all that hassle was necessary so I managed to find a couple of friends with old accounts. They had both forgotten their passwords, but after resetting, they were able to log in easily. So based on this limited testing, I think all that is necessary is to have them log in again. If that doesn't work they can contact our support and we'll go from there.
EMAILS FROM FIREBASE SUPPORT
I understand you, it must be a very frustrating situation, let’s try to find a solution together. I have checked your case and, as you have mentioned, the library is no longer actively maintained, so I’ll escalate your case to our engineering team in order to get any suggestions for your case, please wait a little until they can answer us.
The engineering team has answered and, unfortunately, they have said that old auth tokens have been unsupported for a long time, they suggested you forked the library and try to change firebase.Promise(), which does not exist anymore and then convert that to Promise(), but they can guess other errors will pop up and probably you will need to fix the code.
Thanks a lot for the clarification, I’m so sorry for my misunderstanding. If you want to delete the migration helper, as a workaround, you can export all the users (or only the users having the old token, if you have identified them), delete the users and import them again. This process will re-create the user and it will have the auth latest version because the user would be like a new user, with the same credentials and authentication methods. After that, the user on his side, needs to update the application, log out and log in again in order to update the token.
Please try to do the described workaround with a specific and identified user to limit the scope in case of fail and let me know how it goes.
Nice to hear from you again! Yes, the users will have the same UID and password, as you can see Auth export, the format contains those data and a lot of other more. Unfortunately, based on this, there is no way to know which of the accounts have an old auth token, so, in order to do a test and error approach, I suggest you try to do this with one user (identified old auth token user) to minimize unwanted results.
I have been introduced to Firebase a few days ago. Since then I have been trying to discover more features and usage of Firebase, in particular, the usage of the Firestore/Realtime Database.
However, as I am reading into more details, I start to think of some questions. I hope someone that is familiar with Firebase can help me answer them
As for User authentication, I understand that I can use Firebase Authentication where I won't see their real password. However, technically, everything that user stores in my Firestore would be visible to me since I am the owner of the Firebase.
For example, if I were to develop a note/chat app, in which the user can access their notes/chat on the iOS app and also Android. That means all their notes data would be saved in my database. If it happens to contain some private data, then I would be able to read it?
Even if I set security rules, that would be only facing client-side, whereas, for me, the owner of the entire firebase data, I could see the whole thing. Surely, as a customer, you won't want to use an app knowing that I can see everything you write
I am not sure if what I said is true or not. If true, is there a possible solution?
Both of your statements are correct. This happens in most of the apps-websites, the admin or some core developers have full access to the data. That's why privacy policy and GDPR exist. You must specify what data you collect and for what reason. If you intend to use your user data for any other reason you must inform them. Be aware that if you disclose any user information without his permission you can be held liable.
My app uses Firebase for authentication and I'm having trouble understanding the discrepancy between the number of authenticated users (1027) and the number of installs (4800):
This suggests that a lot of people installed the app but very few logged into it. If so, why would anyone go to the trouble of installing but not using it? Or am I reading Analytics wrong?
Stack Overflow isn't really the right place to ask about human behavior. There could be any number of reasons why someone installed an app and deleted it without even signing into it.
We also don't know if you allow users to delete their accounts after signing in, which could also explain a difference.
We don't know if your users have multiple devices, which would each count as different (anonymized) users in Analytics, but the same user account in Authentication.
There could even be robotic crawlers trying to use the app, especially if it's a web app.
If you're having problem reconciling what you see in the console, you're probably better off contacting Firebase support to see if something is wrong. But something is probably not wrong at all. Consider instead putting some effort into instrumenting your app with more analytics events to figure out exactly how people are using it, and where they might be falling off before they ever sign in, or if they sign in with multiple devices.
I received an answer from Firebase Support and here's what they said:
The active user calculation in our dashboard is based on the user_engagement of your user who access your application while the app is in foreground state. With that, the active user count is not based on the total count of your authenticated user because we track it using the user_engagement event. This is expected that there would be greater number of active users than your authenticated user count if your user didn’t authenticate and they’re using the app within foreground state.
I turns out that the number of 4800 is the number of "engagements" by the app's users, not the number of users. If the user logs in, then goes to another page, that's two engagements. Firebase Analytics is a great way to analyze what people are doing in the app. I love it!
Is this a common/reasonable Use case?
An app allows a user to save favorites locally so that the user doesn't need to signup.
Then the user afterwards desires to share their favorites.
Therefore favorites data needs to be synced from local to remote. The usual local storage for flutter is sqflite, and firebase/store is the remote. However, this seems cumbersome, as sql to nosql conversion is necessary.
I thought that this would be a general issue for UX etc, but I can't find any discussion of this issue? Maybe forcing the user to create an account is the most general solution?
It's a common understanding that if you don't have user account then you can't have any user data associated with your name. You don't have to force the user to have an account or lock them out.
When they favourite something just show a dialog telling them "If you don't have an account your favourites are stored on the device only. If you want your favourites to be available everywhere please create an account" then show options for "Create account" or "No, Thanks"
Create account: Goes to account creation page
No, Thanks: Adds the device to the favourites list and lets the user continue to do what your app does.
There's no problem to solve here from what I'm seeing. If you don't have an account you don't get account functionality. If you track users without them entering anything it's also a little bit illegal and creepy so no need to push the limits on how you can track the same user.
Another way to think of it is to make signup so easy they don't mind and also guarantee that it's worth it. Won't be used for spam or information selling. Take what's app as an example, even though you need to mobile number to send the messages, it's just used as a unique identifier and has nothing to do with the device's number.
Ask for their phone number or email or just any email, you'll most likely get fake info.
And what does your analytics say? Are you getting requests from users saying they lost all their information on a different device? How many people are using your favourite functionality?
I may have come to the party a little late here but here's my 2 cents worth.
The Sql to NoSql conversion is not cumbersome. In fact, there is a reasonable use case for this. I have the same requirement for an app that I am about to build.
Anyway, to store data in RDMDB or NoSQLDB you will need a data model to ensure consistency in your app. If the user has been using the app offline, and they later choose to go online, you can allow them to create the Remote Account, then check if they have local favorites. If they do, you will HAVE to ask them if they'd like to import them into the remote storage. If they choose to do so, you will then have to read their favorites from the local storage and store them in a List<Model> then map() that back to the online storage.
NoSqlDB can accept the json type data, so your model should include the conversion fromMap() and toJson() for this purpose (and others).
When I have come around to doing this, I will share my code (if I remember to come back here).
This question is not related to ASP.NET specifically, but more web applications in general.
I am building a web application wherein I am registering a user. As of now I am taking in very basic credentials like First Name, Last Name, etc of the user. In this website I am giving some information for free for any user who has just registered so that the user finds my website authentic and that it is not a fake website. After that, to get more information, the user has to pay.
The information my site provides will get obsolete after sometime. So, when a new user registers, he/she will get the new information that gets updated; but the old users have to pay to get the same new information.
My problem here is once the information gets obsolete the same person can re-register with a different set of credentials and get the new information. I want to avoid this from happening.
So my question here is this: what information should I request from the user, or extract from the user, to check that the same user is not re-registering? Or any other way to make this possible.
I am thinking of getting the IP address of the machine from which the person is registering and use it to check. But the user can use a different machine to re-register.
I am completely lost here and not getting the solution. I even checked on the Internet but could not find an answer.
Please let me know if you need any further information from my side.
You will not find a technical way to prevent users from registering multiple times. They can simply use another device, IP, another email account and different credentials.
What you can do is asking them to send you hard to fake "offline" information, like a credit card number or a photo of the ID. Some users may still be able to register multiple times this way, but probably not indefinitly. You will however lose many possible clients this way who are unwilling to provide such information for a test account, so this is likely not the solution you want.
My advice would be one of the following two:
Limit the information/service you give out to free users, so that even if they register again they will gain something when they pay.
Try to bind them to their account in a way where they would lose something if they threw it away. This may for example be providing user rewards for activity (real or virtual) or increasing their experience based on their history. Take SO for example: If you registered again, you would lose all your reputation. The users will think twice if this is worth the new content.
After reading all of the above, i think a good solution could be to let the user identify himself through facebook or linkedin. Few people will have a second account.
I think you cannot put any users like that because every thing can be duplicate
There are some ways for which the user must have payment mode or identity details like passport or it is windows application you can have finger scanner it will be definitely Unique..
You can do this (with limitations) with the use of cookies. Setting a cookie on the users device will allow you to determine who the visitor is and that they have already registered.
The limitations are that cookies can be deleted or blocked and are only valid for that specific user agent - the user could use a different device or a different browser on the same device. A lot of people don't really know about cookies though and how to delete them.
By tying this technique with a requirement to provide a valid email address you can make it a hassle for somebody to register more than once as they will have to create a new email account and then delete their cookies.
Whether this will stop enough people depends on your site and your requirements - if you're giving money away then this technique is not nearly good enough. If you just want to discourage the practice of multiple accounts it may be enough.
Your only way out is to have SOMETHING the existing user gets as a "gift?" or added value to maintain just one account. If you can identify items of value to your subscribers and offer to "give" it to them provided their account "attains" one or more status, then you'll get some control. Take stackoverflow.com for example, I don't need a second account.
Identifying by facebook or linkedin is a good option, but if you are giving such services. which are very beneficial for the users, so they dont mind on creating multiple accounts on even facebook or linked in.
So what i think is to set some reward type stuff with each user, and increase the services as they get increment in rewards.once they are good in rewards and are capable to use multiple services, this increases the probability that they will not create another account.