On my android app, I am using Firebase Firestore to store a collection of "usernames" to be queried BEFORE the user signs in to check whether the chosen username is available or not.
Currently my project has 2 main collections: "users" and "usernames". I am trying to allow Read access only in the "usernames" collection. My program fails because when I try to query the "usernames" collection before the user is authenticated it says I don't have the right permissions.
My rules are very basic, but I was wondering if it is possible to modify them in some way for my project to work. Rules are as follows:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
A visual idea what the firestore database looks like:
If you want to treat the "usernames" collection differently than everything else, call it out by name, and assign full read access to everyone:
match /usernames/{id} {
allow read: if true;
}
I suggest taking some time to study the documentation on security rules to better understand how they work, an learn how to make rules on your own.
Related
i am working on a project in flutter with firebase firestore as a database. It has two users Admin and User. Admin has subcollection food_item . is it possible to access the subcollection food_item from the User.
i heard that altering some security rules will help to get access to that subcollection.
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write;
}
}
}
So if it is possible through changing rules can anyone help me. If not can you provide me other alternative reliable solutions.
My application is a local news application that publishes the news and happenings of my village and nearby surroundings. I want people to read all the news without any authentication and only the app owner or publisher can write the news. So, in this case, I have the following rules:
allow read: if true;
allow write: if request.auth.uid =="My uid"
But when I do this I get this message in my email from Firestore:
Your Cloud Firestore database has insecure rules.
We've detected the following issue(s) with your security rules:
any user can read your entire database
You're not showing the entire rules, but if they look like this:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if true;
allow write: if request.auth.uid =="My uid"
}
}
}
Firestore finds that to be insecure because you are applying universal read access to every single document in the entire database. This can lead to unexpected security problems.
Instead, you should call out individual collections that should have read and write access. Don't use the wildcard /{document=**}.
match /collection-name/{id} {
allow read: if true;
allow write: if request.auth.uid =="My uid"
}
I suggest reading the documentation on security rules thoroughly (not just the first page) to learn how they work.
I'm getting the following message in Firebase:
The Cloud Firestore "(default)" database of your project contains
rules that are not secure.
But I have the rules as the documentation says and I don't see any other option. What I want is that anyone can read, but just logged in users can edit content.
These are my rules:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read: if true;
allow read, write: if request.auth.uid != null;
}
}
}
With these rules any authentication user can write all documents in your database, including overwriting documents that were created by other. You're also allowing everyone (no matter if they're authenticated) to read all data in the database, which seem much broader than most apps need. While these are close to some of the default rules you can start with, it is typically not enough for a production app, which is why you receive the warning.
You'll typically want to further lock down access to the database. For example, you might want to ensure that users can only write documents that contain their own UID in a specific field. That way you'll always know who created a document, and can use that to control access to that document.
If you are certain this is the minimum data access that your app requires to function, you can disable the warning emails in the Firebase console. But as said before, in my experience this type of access seems much broader than what I typically see in well functioning, and well protected, apps.
I have files I want to make sure to keep secure, once the admin uploads a file into the storage, only he and the user he is sharing the file with has access to the links to download that file. Hence under firestore rules I added the following:
match /users/{userID} {
allow read: if isOwner(userID) || isAdmin();
allow write: if isOwner(userID) || isAdmin();
}
/// FUNCTIONS BELLOW ///
function isAdmin() {
return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.IsAdmin;
}
However when I tried to add the same rules under Firestorage, the access is constantly denied.
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read: if isAdmin();
allow write: if isAdmin();
}
/// FUNCTIONS BELLOW ///
function isAdmin() {
return get(/databases/$(database)/documents/users/$(request.auth.uid)).data.IsAdmin;
}
}
}
Does the Firestorage get method work differently then the Firestore get method?
Any assistance would be much appreciated.
There are no Firestorage Rules, there are actually rules for Cloud Firestore which is the new database from Google, Firebase Storage which is used to store images, audio, video, or other user-generated content and Fireabse realtime database which is also a NoSQL database.
Cloud Firestore Security Rules
Security rules provide access control and data validation in a simple yet expressive format.
Storage Security
Rules
Storage Security Rules are used to determine who has read and write access to files stored in Cloud Storage, as well as how files are structured and what metadata they contain.
Firebase Realtime Database Security Rules
Firebase Realtime Database Rules determine who has read and write access to your database, how your data is structured, and what indexes exist. These rules live on the Firebase servers and are enforced automatically at all times.
Im guessing you are talking about Firebase Cloud Storage and Firestore
The issue with your Cloud Storage rules is that you cannot access the Firestore database. If you need to carry over data to assist with authorising a write you could look at custom claims Which you could access with auth.token.admin === true in your security rules for example that looks at the users auth token for an admin property
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read: if isAdmin();
allow write: if isAdmin();
}
/// FUNCTIONS BELLOW ///
function isAdmin() {
return auth.token.admin === true
}
}
}
I have a list of existing users in firebase.
I have storage files that should only go to users that are in a group "hasFullAccess" to access all the storage files.
Since we can't add on to the user object, I've added each of the users to the database to give them the extra metadata.
database:
{
users: {
$uid: { hasFullAccess: boolean}
}
}
Now in the storage rules I want to allow users that have full access to be able to access the full content.
service firebase.storage {
match /b/{bucket}/o {
match /files-demo/{allDirPaths=*} {
allow read: if true
}
match /files-complete/{allDirPaths=*} {
allow read: if request.auth != null && // (users have full access?)
}
}
}
If it's possible how can I reference my database in firebase storage rules?
You can't reference values from Realtime Database (or Firestore) from within Cloud Storage rules. Currently, each of these rule systems is completely independent of each other.
What you can do, however, is write Cloud Functions code that responds to changes in each one of these products that can also access the other products in order to check that values are consistent. A full exploration of this topic, and how to use Cloud Functions effectively this way, is outside the scope of a Stack Overflow answer.