Firebase not observing until accessed once [closed] - ios

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
Firebase is configured in APPDelegate.
Read is set to .true in rules.
But, before I have a user sign into my application, I am checking for usernames, within a separate table of my Firebase DB. It would skip the observation block entirely, until I forced signed-in into another already created account of mine. And then when I would re-build the application the block is no longer skipped and actually accesses the table.
How do I "Wake Up" Firebase when I run the app on a fresh device, so I can check for usernames without having to log onto the app with an existing account before hand?

You may want to reconsider how the app is structured.
If you are checking for usernames before being authenticated that means the node is exposed and anyone can grab a copy of all the usernames. Obviously that in itself may not be a huge issue but if your users decide to use an email, whoever grabs the list has a instant list they can spam to.
When you add any observer to a node, that node is read once as soon as the observer is added. When you app starts you can use .childAdded to iterate over an existing node to pre-load some data, a grocery list for example, and then any new grociees added after that will be sent your your app via an event.
Likewise a .value event will read in an entire node and leave an observer attached for any future events.
The username issue is tricky and the way you are doing is now is probably going to get you in trouble in the long run.
A better way is to leverage Firebase Authentication.
Firebase handles all of the usernames and passwords for you. It's very powerful and flexible and avoids the issues you are encountering. It will let you know if user names exist or not, it will do password reset emails and you can manage users from the Firebase Console. It's the way to go.
If you want to add username functionality it can be pretty easily done by adding a username or nickname node to the /users node
/users
uid_0
email: "bill#email.com"
username: "bill_the_cat"
uid_1
email: "clark#email.com"
username: "superman"
Once the user authenticates using Firebase Authentication, from there forward any time the user info needs to be displayed in the app, simply look up the uid that you need (uid_1) and grab the username node (superman) for display.

Related

How to limit access to a database (or a document within a database) based on invitation

From what i've been able to discern so far, Firebase/Firestore seem like the perfect platform to use for an app I am writing. However I can't quite connect all the dots when trying to design my backend. I am hoping that someone will be able to give answer a couple of basic questions about the use of FB/FS.
With my app, a user will be able to share a small piece of data with a select group of friends. ie if the data is to be a To-Do list, the user would create the list on his device (iphone only) and then invite a small group of friends (probably less than 10) to share that data. The friends would have read-only access by default, however, the user can assign any number of them to be "admins" which would allow them read/write permission. When any changes occur to the data, all "friends" who have access to the data will be notified (by some means - push notifications etc). They can manually sync or setup the app to automatically sync. It seems like FB/FS can be used for this right out of the box. However there are a couple of concepts that I can't get my head around.
The database I setup is accessible by ALL users of my app by default. It's not clear (at least to me) how I would set it up so when a user creates (in this case) a to-do list and invites 5 friends, only those 5 friends can access or even know about that data. This is main stumbling block in my development path.
Regarding invitations. I read in the FB/FS documentation that invitations and notifications are among the many features available. I'm not clear on how this will work if a) the recipient doesn't have my app installed and b) how the inviter would get feedback when the invitation was accepted or declined.
Any guidance that anyone is willing to share to help me get started will be a huge help and will be greatly appreciated. Thanks.
You can create new privates collections inside the main collection, and set different rules for access.
Check at: Firebase Firestore get private fields

Get the details of user by comma separated user_id from Firebase

I am working with Firebase database for my application. I have one scenario where I need to display list of Call detail screen where each user's call history should be display. In firebase database I have two main node
Here is the image of the both node.
1) Users - user node have user related data with basic details of name,email and other stuff
2) Calls - user's call history each call have user_id which is related to in Users node for his/her basic details.
Now I want to details (first_name,last_name,email) of user_id from Calls node each entry or each object. So is there any solution for getting details via passing a comma seprated user_id list and getting its details from Firebase. Or is there a any other solution to fetching basic details.
Thank you in advanced if any one have faced this and provide a solution on this.

How to structure properly Firebase Database?

I read some Firebase database structure guides on how to structure your data properly (without data nesting) but I have one question.
So, I have an iOS app that uses Firebase database. The users need to login/register.
In terms of data structure, my database looks like this:
-Database
---Users
-----User1
--------username: johndoe
---------email: johndoe#test.com
---------display_name: John Doe
-----User2 {....}
-----User3 {....}
Now, let's imagine I have 100K users in there. Every time a new user is being registered, I check if the username & the email already exist in the database, if they don't then create the new user account.
My question is - Do I need to create a new object that contains only the usernames and another that contains only the emails? I'm asking this because I'm concerned that if I iterate through the Users objects I will potentially be downloading hundreds of megabytes just to check if the username and the email already exist.
Firebase will not allow duplicate users (authentication names). So when you call createUser, firebase will return an error if the user already exists.
Secondly, if you are performing a query for a specific item in Firebase, you are not downloading anything unless that item is found. So whether its 10 or 100k user nodes, nothing is downloaded when performing a query other than the nodes that match the query, which would only be one if there was a duplicate user. again though, this is not needed since Firebase rejects duplicate authentication names.
And to clarify; there is nothing wrong with nesting nodes. However, keeping them flat is usually better depending on your use case. So don't go overcomplicating your structure if you don't need to.
Oh, and your Firebase structure is spot on. Keep going with that.

Firebase: How to identify registered contacts?

I am writing an app, where a signed up user should be able to see which of his contacts have signed up, too. What is the most elegant way to do this?
I was planning to create an array of all locally saved email addresses extracted from the user's local iOS addressbook and create a query for those. Is there any better way to do this?
Edit: Is this actually possible without downloading the whole user list? I could use a for loop with queryStartingAtValue(emailAddress) and queryEndingAtValue(emailAddress). But this could possibly lead to hundreds of queries at the same time.
In NoSQL databases you'll often end up modeling the data in ways that your application wants to consume it.
In this case it seems your app needs to look up whether a user exists, based on their email address. For that purpose I'd add a list of email-to-uid data:
emailToUid
"test#mail,com": "P0...wklsh1"
"MJQZ1347": "Aj1278a..."
This is essentially a self-created index that allows you to check whether an email address is used without having to run a query.
Now you can loop over the contact and look whether there is a user for that email address with a:
ref.child("emailToUid").child(email).observeSingleEventOfType(.Value
This is going to be very fast. Because of the way Firebase communicates with the back-end, there's going to be very little difference between a single request with 100 email addresses or 100 requests with a single email address. See my answer here for more on that: Speed up fetching posts for my social network app by using query instead of observing a single event repeatedly
You could have something like this
user
-$user_id
-email
-username
-contacts
-contact_uid1:email1,
-contact_uid2:email2,
-contact_uid3:email3,
And then do:
Download the contact child from firebase and save it to a var
Create the loop to check every contact in the address book
If the email is in the contact child don't do anything (it means you already verified the user once)
If the email is not in the contact child launch a single event query to find the uid of an specific email
in the callback of the query if it is nsnull the user is not in the app
if the user exist, add the user to your contacts child node in firebase
This way you only launch the queries of the contacts you haven't checked

Parse iOS Destroy Button (Password Validation Dependent) Client side

I'm starting to create a lot more features for users in my app. I've run into some app structure issues.
lets say I have User Fooman
Fooman wants to edit his account, delete some objects(wall posts), update his friends list etc.
Fooman is logged in to do all of these. But footman isn't the one using the device at the moment. It's fooman son (foobaby). Foobaby decides to just be a son and delete things erroneously. I have an option for users to delete their account client side. I present them an alert view to confirm that's the choice they meant to select. After they confirm that, another view populates with a 'Destroy' (or delete button) that will delete the User, plus all relations/pointers/data connected to it. Before that button is enabled a password validation check is required so it's not done by a foobaby. However, with Parse, this has proved to be problematic client side. I don't use cloud functions because, well, simply put, at this point in time my app is one platform and doesn't really need to use it.
Is there any workaround anyone has come up with that's quick/efficient, API friendly for validating a textField.text with the [PFUser currentUser].password whilst maintaining security of course.
I code in Objective-C :)
Note: I have tried numerous things but nothing seems to work outside of trying to log them in against the user input (UITextField), which doesn't feel like the right way to do it in my opinion.
I think it's an unusual requirement. The idea of a logged-in user is that the app trusts the user. A persisted logged-in user on the device means that the app trusts whomever is holding the device. So FooBaby is trusted, because FooDad let him hold the phone.
Some apps put up a barrier to establish thoughtfulness, like the Parse data browser requiring that you type the name of a class before you drop it. But this establishes thoughtfulness, not trust. (For a child, I guess it also establishes minimal competence, in case FooBaby knows how to press buttons, but not how to spell).
Otherwise, I can't think of how to do it besides requiring a login, which you mentioned you find unappealing (though you didn't say why). Excluding that, I don't think there's a way to do it without spoiling security with something like keeping an in-the-clear copy of the password.

Resources