Thank you for your feedback, Sahan! Don't forget to check out the Codelab link below for a more hands-on experience 😄: Protect Your Data with Firestore Security Rules → goo.gle/3Hoh64w
Just getting started with them (already behind the 8-ball as I developed app with auth barely in the back of my mind) ... this was great info. Going to catch some more videos before I embark ... and will still be ready to revamp as I get more familiar with it.
I think there's a bug in this example: `allow create: if resource.data.ownerUID == request.auth.uid`. In a create scenario, resource will always be null and that rule will always throw an exception, resulting in permission denied. I think you want `request.resourse.data.ownerUID`.
This is actually not a bug. It insures that no body can hijack the user session and in your front end you have to provide the Auth.UID within the payload of your document. So every document has owner (Auth.UID). Hope it's clear now.
I think it is a bug too. As a matter of fact at 4:09, they tell you that "Resource object is the document that the user is trying to access as it is currently written in the database. If this is the create method, the resource object will be empty."
I watched this video earlier and found you were answering questions that I had in mind, and I didn't know your Firebase videos included explanations to further knowledge on your Firebase docs, so it's really good to get this practical side from you and I will definitely be looking out for more ... It was Todd's video on unit testing that had me seeking videos by Rachel ... I think to add to the learning that is intended, that screenshots of the Firestore environment could be included for an explanation of how the values in rules or within Firestore correspond ... Right now I'm at 4:47 and I have a question ... The rule says allow 'create' if the ownerUID of an existing todo-collection document matches the user-identity of the current user ... My question is, would this rule work? Because 'create' seems to initiate a new document, so then I expect there to not be an existing document that would be relevant, or, at the very first time this rule is run, I would expect there'd be no possibility of a corresponding document ... Am I correct in this view or is there something I have misinterpreted here please?
At 5:14 I have just noticed something for the first time ... The get( ) call begins with the name of the collection and not with /databases/{database}/documents/ etc ... My question is, under which circumstances could I get away with making a get( ) call in this way please? When is it okay to leave out /databases/ etc. and if the collection within the get( ) call is a sub-collection, could that collection be stated without also stating its parent collection?
Hi Bost, check out this other video I made earlier: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-rbuSx1yEgV8.html (Getting started with Firebase Authentication on the web - Firebase Fundamentals) - it covers how to monitor authentication state using onAuthStateChanged.
@@PeterFriese Hi there, I have tried this already, however when I try logging in to one page, it says my user is null on other pages. This is very frustrating as the user has to login to each page that requires login.
Question: I have used firebase for Unity extensively, within the Unity library you can import just firebase.authentication as a library and use it for authentication purposes. Now I am working on a python project using Django, and I want to use Firebase, I can see that there are some third-party libraries like pirebase, pirebase4 but no official firebase python library for authentication. Is the firebase_admin library a good choice? as it's available for python and does authentication.
Rules are written at the document level, not the field level. You can write a rule that only allows updates if a specific field is updated, but if you want to set different access controls on a specific field, pull that into a different document. Subcollections are great for that.
A rule can't "overwrite" another rule; any rule can grant *additional* access. This grants global access to admins; modify for however you're tracking admins: ``` rules_version = '2'; service cloud.firestore { match /databases/{database}/documents { // Allow admins to read or write to any document match /{document=**} { allow read, write: if auth.token.isAdmin == true; } // Rules for non-admins // Blog posts match /posts/{postID} { allow create: if ; ... } } } ```
