From numerous other posts, it seems that the recommendation for creating the structure for one to one chat seems to be to combine two user IDs, taking into account their natural ordering. For example:
root{
messages:{
user1_user2:{
//messages here
},
user1_user3:{
//messages here
}
}
}
Seems fine and is much more efficient than creating a personal message topic for each user. So my question now is what would be the best way to secure this? Right now I have the following:
"messages":{
"$channel":{
".read": "$channel.beginsWith(auth.uid) || $channel.endsWith(auth.uid)"
}
}
Is this sufficient? Can't shake the thought that it's possible for a different but longer user id that starts or ends the same way will get past this check
Related
I’ve seen all around the documentation that Query-based sync is deprecated, so I’m wondering how should I got about my situation:
In my app (using Realm Cloud), I have a list of User objects with some information about each user, like their username. Upon user login (using Firebase), I need to check the whole User database to see if their username is unique. If I make this common realm using Full Sync, then all the users would synchronize and cache the whole database for each change right? How can I prevent that, if I only want the users to get a list of other users’ information at a certain point, without caching or re-synchronizing anything?
I know it's a possible duplicate of this question, but things have probably changed in four years.
The new MongoDB Realm gives you access to server level functions. This feature would allow you to query the list of existing users (for example) for a specific user name and return true if found or false if not (there are other options as well).
Check out the Functions documentation and there are some examples of how to call it from macOS/iOS in the Call a function section
I don't know the use case or what your objects look like but an example function to calculate a sum would like something like this. This sums the first two elements in the array and returns their result;
your_realm_app.functions.sum([1, 2]) { sum, error in
if let err = error {
print(err.localizedDescription)
return
}
if case let .double(x) = result {
print(x)
}
}
I am using firebase for simple chat application. I am looking to fetch messages of user 1 and user 2. My database structure look like this.
I am using queryOrdered to fetch messages but it will filter with either sender or receiver.
Database.database().reference().child("Chats").queryOrdered(byChild: "receiver")
.queryEqual(toValue: "2WCS7T8dzzNOdhEtsa8jnlbhrl12")
.observe(.value, with: { snapshot in
})
But using this code I got messages of receiver only. How can I receive messages of sender as well. Can I use AND condition to query sender child?
There is no way in your current data structure to with a single query get both the messages that a specific user sent and received.
Firebase Database queries can only order/filter on a single property. In many cases it is possible to combine the values you want to filter on into a single (synthetic) property.
For example, you could combine the sender and receiver UID into a single properties "sender_receiver": "2WCS7T8dzzNOdhEtsa8jnlbhrl12_Sl91z...." and then query for that combined value.
For a longer example of this and other approaches, see my answer here: Query based on multiple where clauses in Firebase
For most chat applications however I recommend creating a database structure that models chat "rooms". So instead of having one long list of all messages, store the messages in rooms/threads, which is also what you show in the UI of your app.
"-RoomId1": {
"msg1": { ... },
"msg2": { ... }
}, "-RoomId2": {
"msg3": { ... },
"msg4": { ... }
}
That way you have the most direct mapping from the database, to what you show on the screen.
For a good way to name the "rooms", see Best way to manage Chat channels in Firebase
You'd then still store a mapping for each user of what rooms they're a part of, which might also be useful in securing access.
I have application which have multiple users, one of the major thing left is to block and report users in firebase.
I am trying to look for the solution for the same by googling for it, but till now not any particular success.
I would like to know how I can achieve that. Please guide me for that,
and how the firestore security rules should be to achieve the same?
The typical approach is to have a collection that contains the blocked users, with one document for each blocked user and with the ID of that document being the UID of that user.
With that structure in place, your security rules can check for the existence of such a document and then block the user.
There's a great example of this in the blog post 7 tips on Firebase security rules and the Admin SDK (it's tip 7). The rules from there:
service cloud.firestore {
match /databases/{database}/documents {
function isBlackListed() {
return exists(/databases/$(database)/documents/blacklist/$(request.auth.uid))
}
// Collections are closed for reads and writes by default. This match block
// is included for clarity.
match /blacklist/{entry} {
allow read: if false;
allow write: if false;
}
match /posts/{postId} {
allow write: if !isBlackListed()
}
}
}
I am working on a Forum-like structure using Firebase Store / Firebase Rules. My structure is something like this:
Collection --- Document ------ Collection --- Document
Topic1 CreationDate UsersJoined UserUID1
Topic2 Title UserUID2
Topic3 UpdatedDate UserUID3
... ... ...
Basically, each Topic has a Collection of Users. My goal is to be able to write a security rule where only Users in the 'UsersJoined' can read/write to the corresponding Topic. This is what I have right now as my rules:
service cloud.firestore {
match /databases/{database}/documents {
match /Topics/{topicUID} {
allow read, create, update, delete: if exists(/databases/$(database)/documents/Topics/$(topicUID)/UsersJoined/$(request.auth.uid));
match /UsersJoined/{userUID=**} {
allow read, create, update, delete;
}
}
}
}
So when I use the built in Simulator, the read works just fine; however, when I request to read it via my code for IOS, it tells me that I don't have sufficient permission.
I've tried just doing allow read: if request.auth.uid != null;, and I am able to read. I am confident that the UserUID does exist within the UsersJoined collection.
I've also tried creating a "sister" collection where I store my User IDs in, so my structure looks like this:
Collection ----------- Document
MyTestUserCollection UserUID1
Topic1 UserUID2
Topic2 ...
...
I then used this rule: if exists(/databases/$(database)/documents/MyTestUserCollection/$(request.auth.uid)); and the read works as well, both on the simulator and IOS codes.
My problem is not being able to read when the User List is nested within the Topic. So my question is... by writing a rule that checks ("reads") data in a nested collection, am I violating the "allow read" rule (since technically it hasn't determined whether I can read yet)? Or am I over complicating things a bit and there is a better way to structure my Collections/Documents? Or am I just not writing the rule correctly?
I don't believe my code on IOS is the issue, but just in case this is what I'm doing to request to read from my database: (the user is logged in via Firebase Auth)
[[myFirestore collectionWithPath:#"Topics"]
getDocumentsWithCompletion:^(FIRQuerySnapshot *snapshot, NSError *error) {
if (error != nil) {
NSLog(#"Error getting documents: %#", error);
} else {
NSLog(#"Read it");
}
}];
Any help is greatly appreciated!
Your security rules allow a user to read a specific topic, if they are following that topic. Your code tries to read all topics, which your rules don't allow. So that explains why the server rejects the read operation.
This is easiest to remember by realizing that rules themselves don't filter data. They instead either allow a listener or not. And since your rules don't allow a listener on all of /Topics, that listener gets rejected.
One solution is to only read the specific topic that you are a follower of. To determine the topic(s), you might need to store a document with the user's list of topics, such as in a /Profiles collection. This is quite common on NoSQL databases: you're essentially storing both sides of the many-to-many relationship.
Alternatively you can try to validate the query, but I'm not quite sure if that can be made to work for your situation.
The childByAutoId would be useful if you want to save in a node multiple children of the same type, that way each child will have its own unique identifier.
List:{
KJHBJJHB:{
name:List-1,
owner:John Doe,
user_id:<Fire base generated User_id>
},
KhBHJBJjJ:{
name:List-2,
owner:Jane Lannister,
user_id:<Fire base generated User_id>
},
KhBHJZJjZ:{
name:List-3,
owner:John Doe,
user_id:<Fire base generated User_id>
}
}
I am trying to access the List with the help of the following code:
let ref = FIRDatabase.database().reference(withPath: "/List")
The current user logged into the app is John Doe. When the user accesses the list, I want all the List child whose owner is John Doe(i.e. List-1 & List-3) and ignore the other child values.
Do I have to do this in my application or can this be achieved via Firebase Security rules?
My current rule definition is:
"List":{
".read": "root.child('List/'+root.child('List').val()+'/user_id').val() === auth.uid" }
But this rule is not giving me any success. Any idea how to achieve the desired result?
You're trying to use security rules to filter the list. This is not possible and one of the common pitfalls for developers coming to Firebase from a SQL background. We commonly refer to it as "rules are not filters" and you can learn more about it in:
the Firebase documentation
this answer
our new video series Firebase for SQL developers
and many previous questions mentioning "rules are not filters"
The solution is almost always the same: keep a separate list of the keys of posts that each user has access to.
UserLists:{
JohnUid: {
KJHBJJHB: true,
KhBHJZJjZ: true
},
JaneUid: {
KhBHJBJjJ: true
}
}
This type of list is often referred to as an index, since it contains references to the actual post. You can also find more about this structure in the Firebase documentation on structuring data.