0
355
ViewsWhy does this still allow the user to write even if the userID is not correct but the email is correct?
I created a user using this:
And this is how they will log in to the system:
const handleSubmit = async (e) => {
e.preventDefault();
const auth = getAuth();
console.log(email, password, "1");
setIsLoading(true);
signInWithEmailAndPassword(auth, email, password)
.then((userCredential) => {
// Signed in
const user = userCredential.user;
setIsLoading(false);
navigate("/Homepage");
// ...
})
.catch((error) => {
const errorCode = error.code;
const errorMessage = error.message;
setIsLoading(false);
alert(errorMessage);
});
};
I am setting up the Firestore where only the logged-in individual will be able to create and write in all of the collections orders, product, category, and the subcollection history. Which means, all authenticated users will be able to read and write in all of the collections and subcollections.
This is the Firestore collection:
Firestore security rules:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Now, I'm testing this with the Rules playground, however, it will still allow access even if the userID is wrong and the email is correct. Is there something wrong with my Firestore security rules or Am I doing the Rules playground incorrectly?
1 answers
Answer question0
Is there something wrong with my Firestore security rules or am I doing the Rules playground incorrectly?
Neither, it just works slightly different than you assume.
The Security Rule doesn't check whether your provided uid matches email, hence any uid and any email in your auth object (see panel "Authentication payload") will pass your Security Rule in the Playground. It passes because as you can see in the Payload panel, request.auth is not null.
Now, you assume that anyone can just send any uid and any email to Firestore and pass your Security Rule. This is not the case.
Your user does not create the object you see in the "Authentication Payload" panel - Firebase does this for you behind the scenes when it receives the request from the client.
Your users have to send a token along with the request. This token is the "glue" between a user session and a specific user in Firebase Auth. Firebase verifies that the token is valid and then adds the authentication details as auth to your request. In Firestore you have access to those authentication details in the Security Rules.
In the Playground you take over the role of Firebase Auth and decide what is the Authentication Payload. Firestore assumes your input is correct and tests it against the Security Rule you have provided. Your auth payload passes the test because you only test whether it is not null.
TL&DR: Your Security Rule is ok, the Playground just assumes you have generated a valid Authentication Payload. In the real world, Firebase would generate this payload for you.