I'm making an app where i'm using firebase as a database(a free plan i.e 100 concurrent users at a time). Let say user comes to my app, register and gets logged in and is not supposed to log out of the app.
The confusion for me is that does that logged in user be counted as
a concurrent user on firebase? Even if the user closes the
app(without logging out), is this be still counted as concurrent? Or
else firebase will itself remove that particular user from the row?
Secondly when should i use goOffline? I am not sure about what it
actually does.
I have already gone through the present look a like SO questions but they didn't cleared my confusion. Thank you in advance
A "concurrent user" is a user who has your app open and is maintaining a socket connection to the database. This connection will be broken when the app is no longer working. So, users who are not actively using your app with an open connection do not count as a "concurrent user".
Use goOffline when you want the database connection to be closed until you call goOnline, or the app is killed and the user launches it again. A vast majority of apps don't have a use for this.
Related
So I have an app where I have enabled google authentication in my firebase project. 25 people I know were authenticated. When I logged in the backend I saw atleast some 80 entries with some weird sounding email addresses which should not be there. I had to delete all the entries manually, known and unknown ones (didn't needed any after sucessful testing). Now that I want to go live, I am really concerned as to how unknown entires entered my firebase authentication records?
This has recently happened 'again' to another new app/project of mine. This time I disabled that unknown email address and took a screenshot (attached).
I really really need to know and understand how safe is data on firestore. If someone can manage to 'hack' the Authentication part and add thir email to Authenticated list of users they may also be able to penetrate the database somehow in future. Please help me in understanding what is happening?
While researching on this, I could only find this similar question but the answer was just not enough explanation for me.
Unknown user in my firebase user authentication (Flutter/firebase)
firebaser here
Since the configuration data for your project is embedded in the application that you send to your users, any user can take that configuration data and then start calling the API with it. This is not a security risk, as long as you secure access to the data within your project correctly for your requirements.
See Is it safe to expose Firebase apiKey to the public?
What it means to correctly secure access to your data is hard to answer, as it depends completely on your use-case.
For example: the content-owner only access security rules allow a user to enter data in the database, and then they can access the data they entered. With these rules there's no risk if anyone uses the API (and not your app) to do the same. The security rules will ensure they only can access data they're authorized for, no matter what the source is the API calls is.
It may be related to the pre-launch report.
https://support.google.com/googleplay/android-developer/answer/9842757?visit_id=637478112313064713-650300184&rd=1#signin
Step 1: Provide test account credentials if your app has a sign-in screen
If your app has a sign-in screen and you want the crawler to test the sign-in process or the content behind it, you need to provide account credentials. Note: You do not need to provide credentials if your app supports 'Sign in with Google', which enables the crawler to log in automatically.
So I guess it is safe.
The user willwhiteapple#gmail.com is the apple testing when your application is in the process of validation from apple before deploy to TestFlight .
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!
Since I have noticed that once a user signs in with email and password, on reopening the application the session will not have expired and there is no need for a new authentication, I wish to avoid this.
I want to automatically .signOut() a user when .onDisconnect is triggered. How can I achieve this? I have tried with the following code, but unsuccessfully:
firebase.auth().onDisconnect().signOut();
When you say "onDisconnect", I'm assuming that you mean Realtime Database onDisconnect triggers.
The first thing to know about onDisconnect is that it triggers when the socket connection between Realtime Database and the client app is closed. This could happen for any number of reasons, and it can happen at any time, even if the app seemingly has a good internet connection. So, be careful about what you're trying to do here.
Also, onDisconnect triggers can only affect data in the database directly, and nothing else. So, this limits what you can effectively accomplish. You can't perform any action in the client app in response on an onDisconnect.
Between these two facts, what you're trying to do isn't really possible, and, I don't think it's desirable. You could end up logging out the user just because their train went underground momentarily, or if they simply switched out of the application for some time. This would be massively inconvenient to the user.
If you want to automatically log out the user, I strongly suggesting finding some other way to do this, such as writing some code to remember how long it's been since the user used your app, and forcing the logout on the on the client app based on your preferred logic.
The onDisconnect() is related to the database connection, and has little to do with your authenticated user. As in: onDisconnect() may fire when your user is signed in, simply because the connection to the database drops temporarily.
But more importantly: onDisconnect handlers run server-side, once the server detects that the client has disappeared. When this is because if a dirty disconnect (e.g. the app crashes), there is no way for the client to detect this anymore.
The most likely approach you'll want is to simply sign the user out when they close the app.
Alternative you might want to attach a listener to .info/connected in your client. This is a client-side listener that fires when the client detects that it is connected or disconnected.
How to manage concurrent connections of the same user. Is there any way I can limit how many connections my user can keep active?
I could make my database something like:
"users": {
...
"FAKE-USER-ID": {
"active_connections": 2
}
...
}
And update the key active_connections whenever a user changes their state.
How cases like connection lost and app crashes would be managed in this scenario? Is there a Firebase native way of doing this?
To handle when the user connects, look at .info/connected. You could use this to set a flag when the user connects.
To handle when the user disconnects (either by closing the app or because they lose their connection), look at onDisconnect(). You could this to remove the flag when the user disconnects.
But why would you want to limit the user to only access their data on a single device? Firebase doesn't charge per connection, so why would you want to limit it on that?
A few years ago I was using an app that exhibited this exact behavior and I found myself locked out of the app multiple times per day. I moved over to another app.
I would like to ask, if it is a good idea to use SinglR just for knowing if the current user now online or not?
For example I have an small website with log in system, and some where on the side i would like to show the logged in members.
Is this a good idea to use signalr for that?
And if it the case should I then on each page start the connection with hub? (In this case when user navigates on the pages, will be the ReConnected method called on hub, or OnDisconnected and OnConnected)?
I'm just starting with signalr, so curious what ppl think.
You could use SignalR though there might be better methods to do this. So when a user logs in, logs out or becomes inactive - you would have some sort of message being sent from the client to the server that indicates the change in status. You can store that information in a temporary database and whenever a value in the database changes you can use SignalR to relay that information to all the connected clients.
Signalr will get reconnected when the user moves from one page to another page. Whenever a user logs into a website the user security details will be persisted in a cookie assuming you are using Cookiebase authentication. So till the user logs out or session timesout the cookie will be active. So there is no real need for Signalr here.
I have been investigating the same thing. From my research, I would say that you COULD do this, but I'm on the fence of whether it's the best way to go about it. I would expect a LOT of disconnecting, connecting and reconnecting. If you're persisting this data in a database, you should anticipate a lot of database traffic. if you're only on a single server though, you could just persist this in memory.
Something to also note is that the ConnectionId changes with each page refresh. At first, I thought that was dumb because I wanted the connection id to be consistent so i could keep a handle on a user with it. However, if you open a link in a new tab and then close one of them, you have to still keep the other connection in storage. If the id was the same you would remove it on disconnect even though the other tab was open, so your user would incorrectly be marked as offline.
However, the other issue that i'm thinking about is that if you're just browsing around the site in a single tab, you will disconnect for a split second between each page load. So you might run into connection consistency issues with that.
I'd say online presence with signalr is more common to be used for a chat room or game lobby. So I'd say this is possible, but whether it's a good solution -- i'm unsure.