Welcome to fireact Discussions!

[chaoming]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.
• Showcase your project based on Fireact.
• Advertise jobs that needs developers on your Fireact project.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[guiziii]

Loved the project! I tought it would be nice to know more about the firestore rules inside the fireactjs's documentation. It was AI, but i think it could be important

Here's an explanation of each rule:

Rule 1: Payment Methods

match /users/{userId}/paymentMethods/{paymentMethodId} {
    allow read, update, create, delete: if request.auth.uid == userId;
}

This rule applies to any document under the paymentMethods collection that is nested within a specific userId under the users collection. The rule allows read, update, create, and delete operations if the userId of the document matches the authenticated user's ID (request.auth.uid). This ensures that users can only access and modify their own payment methods.

Rule 2: Subscriptions

match /subscriptions/{subscriptionId} {
    allow read: if request.auth.uid != null && request.auth.uid in resource.data.permissions.access;
    allow update: if request.auth.uid != null && request.auth.uid in resource.data.permissions.admin && (!request.resource.data.diff(resource.data).affectedKeys()
        .hasAny(['currency', 'ownerId', 'paymentCycle', 'paymentMethod', 'plan', 'price', 'stripeItems', 'stripeSubscriptionId', 'subscriptionCreated', 'subscriptionCurrentPeriodEnd', 'subscriptionCurrentPeriodStart', 'subscriptionEnded', 'subscriptionStatus']));
}

This rule applies to documents in the subscriptions collection:

• Read: Allows the operation if the authenticated user ID (request.auth.uid) exists and is listed in the permissions.access array within the subscription document. This permits access to subscription information to a predefined set of users.

• Update: Allows updates only if the authenticated user ID is listed in the permissions.admin array and only if the update does not modify specific critical fields (like price, plan, paymentMethod, etc.). This protects sensitive subscription information from unauthorized changes, even by users who are otherwise allowed to make updates.

Rule 3: Invoices Nested in Subscriptions

match /subscriptions/{subscriptionId}/invoices/{invoiceId} {
    allow read: if request.auth.uid != null && request.auth.uid in get(/databases/$(database)/documents/subscriptions/$(subscriptionId)).data.permissions.admin;
}

This rule allows read access to documents under the invoices subcollection within a specific subscription document, only if the authenticated user's ID is listed in the permissions.admin array of the corresponding subscriptions document. This means that only administrative users of a subscription can view its invoices.

Rule 4: Invites

match /invites/{inviteId} {
    allow read, delete: if request.auth.uid != null && request.auth.token.email == resource.data.email;
}

This rule applies to documents in the invites collection, allowing read and delete operations if the authenticated user's email (request.auth.token.email) matches the email stored in the invite document (resource.data.email). This ensures that invites can only be accessed or deleted by the invitee.

These rules collectively ensure data integrity and security, making sure that users can only access or modify data for which they have appropriate permissions.