Firebase allow read, write: if true ახსნილი: რას აკეთებს და როგორ გავასწოროთ

სინტაქსი ხაზ-ხაზად

სრული Firestore ტესტ-რეჟიმის წესების დოკუმენტი არის ექვსი ხაზი:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

გაშიფრულია:

• rules_version = '2'; ირჩევს v2 წესების ძრავას (მიმდინარე). ძველი v1 წესები ფარდულია.
• service cloud.firestore არიდებს ბლოკს Firestore-ზე. Realtime Database იყენებს განსხვავებულ JSON-ბაზიან სინტაქსს; Cloud Storage იყენებს service firebase.storage-ს.
• match /databases/{database}/documents შებოჭავს სპეციალურ (default) მონაცემთა ბაზას (პროექტების უმეტესობას ერთი აქვს).
• match /{document=**} არის რეკურსიული wildcard. ** ემთხვევა ნებისმიერ გზას ნებისმიერი სიღრმისა. შერეული {document}-სთან, ეს იჭერს ყოველ დოკუმენტს ყოველ კოლექციაში — ერთი match-კონსტრუქცია მთელ მონაცემთა ბაზას მართავს.
• allow read, write: if true; არის წესის სხეული. read და write ორივე დასაშვებია; პირობა if true არის, კარგი, ყოველთვის ჭეშმარიტი. read ფარავს get და list ოპერაციებს; write ფარავს create-ს, update-ს და delete-ს.

წმინდა ეფექტი: ნებისმიერ კლიენტს Firebase-პროექტის ID-ით და სწორი SDK-ით შეუძლია წაიკითხოს ან ჩაწეროს ნებისმიერი დოკუმენტი ნებისმიერ კოლექციაში. ავთენტიფიკაცია არ არის საჭირო. სიხშირის ლიმიტები არ აღსრულდება.

რატომ ცვლის Firebase ამას როგორც ნაგულისხმევს

Firebase სურს, რომ თქვენ კოდირებთ პროექტის შექმნიდან პირველი 30 წამის განმავლობაში. ალტერნატივა — გაიძულოს დაწეროთ სწორი წესი ნებისმიერი წაკითხვის ან ჩაწერის მუშაობამდე — დაბლოკავდა მიღებას. ამიტომ Console გვთავაზობს ორ ვარიანტს მონაცემთა ბაზის შექმნისას: Production mode (უარყავი ყველაფერი, თქვენ წერთ წესებს) ან Test mode (დაუშვი ყველაფერი 30 დღით). უმეტესობა დეველოპერების აწკაპუნებენ ტესტ-რეჟიმს, შემდეგ ივიწყებენ თავიდან მონახულებას. ძველი პროექტებს ჰქონდათ 30-დღიანი ტაიმერი; მიმდინარე პროექტებს აქვთ განუსაზღვრელი if true წესი ავტომატური ვადის გასვლის გარეშე.

სტრუქტურული პრობლემა: AI-კოდირების ხელსაწყოები ვარჯიშობენ დოკუმენტაციაზე, ტუტორიალებზე და Stack Overflow-ის პასუხებზე, რომლებიც აჩვენებენ ტესტ-რეჟიმის წესებს. როცა Cursor-ს ან Claude Code-ს ეკითხებით „როგორ დავაყენო Firebase", პასუხი ხშირად შეიცავს ზუსტ allow read, write: if true ბლოკს, თითქოს ის იყოს პროდუქციის წესი. AI-მ არ იცის — და არ არის სთხოვილი იცოდეს — რომ ეს წესი არ არის უსაფრთხო პროდუქციისთვის.

რას ხედავს თავდამსხმელი

კონკრეტულად, თავდამსხმელი, რომელმაც იცის თქვენი Firebase-პროექტის ID (ამოღებადი ნებისმიერი დეპლოიდი აპის ბანდლიდან 30 წამში) და უშვებს შემდეგს, შეუძლია ჩამოთვალოს ყოველი დოკუმენტი ყოველ კოლექციაში:

ერთი არაავთენტიფიცირებული curl-მოთხოვნა საკმარისია ყოველი კოლექციის ჩამოსათვლელად. ნახეთ ხაზგასმული ბლოკი ქვემოთ.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

პასუხი არის ზედა-დონის კოლექციების სრული სია. ყოველი კოლექციისთვის, მეორე მოთხოვნა აბრუნებს დოკუმენტებს. ამ გზაზე სიხშირის ლიმიტი არ არის, რადგან if true წესები ანონიმურ ტრაფიკს იღებენ. ჩვენ ვნახეთ Firebase-მონაცემთა ბაზები მილიონობით დოკუმენტით, ჩამოთვლილი ერთ საათში.

ჩაწერის გზაზე: ერთი POST {fields}-ით ქმნის ახალ დოკუმენტს. თავდამსხმელებს შეუძლიათ თქვენი კოლექციების დაბინძურება ნაგვით, მომხმარებლისთვის ხილული გვერდების დეფეისი, რომელიც Firestore-დან კითხულობს, ან თქვენი მონაცემთა ბაზის გამოყენება უფასო შეტყობინების ბროკერად — თქვენი გამოყენების ანგარიში იზრდება, თქვენ იძიებთ, ანგარიში ხსნის პრობლემას.

ოთხი პროდუქცია-უსაფრთხო შეცვლა

აირჩიეთ შეცვლა, რომელიც ემთხვევა თქვენი აპის მონაცემთა მოდელს. ოთხივე ვარაუდობს, რომ თქვენ გაქვთ მომხმარებლის ავთენტიფიკაცია (Firebase Auth ან ნებისმიერი პროვაიდერი, რომელიც გასცემს Firebase ID-ტოკენს):

ვარიანტი 1: მომხმარებლის-მფლობელობის დოკუმენტები

ყველაზე გავრცელებული SaaS-შაბლონი. დოკუმენტები ცხოვრობენ /users/{userId}/...-ში და მხოლოდ მფლობელს შეუძლია მათ შეეხოს. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

ვარიანტი 2: მფლობელის ველი ყოველ დოკუმენტზე

როცა დოკუმენტები ცხოვრობენ ბრტყელ კოლექციებში (არ არიან მომხმარებლის ID-ის ქვეშ), შეინახეთ owner_uid ველი და შეამოწმეთ ის. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

ვარიანტი 3: მრავალ-არენდატორის ორგ-იზოლაცია

B2B SaaS-ისთვის ორგ-არიდულ მონაცემებთან. შეინახეთ org_id ველი ყოველ დოკუმენტზე და შეამოწმეთ მომხმარებლის კასტომ-claim-ის წინააღმდეგ. allow read, write: if request.auth.token.org_id == resource.data.org_id;. მოითხოვს კასტომ-claim-ის დაყენებას რეგისტრაციისას Firebase Admin SDK-ით.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

ვარიანტი 4: წაკითხვის-მხოლოდ საჯარო შინაარსი

მარკეტინგული შინაარსისთვის, საჯარო პროფილებისთვის, პროდუქტის კატალოგებისთვის — ნებისმიერი რამისთვის, რომელიც ნამდვილად საჯარო-წაკითხვადია, მაგრამ მხოლოდ-ადმინ-ჩაწერადი. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin კასტომ-claim მხოლოდ ადმინ ანგარიშებზე არის დაყენებული.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

სწრაფი აუდიტის შეკითხვა

გასწორებამდე შეამოწმეთ, ცოცხალია თუ არა if true სინამდვილეში. გახსენით Firebase Console → Firestore → Rules და ეძებეთ if true. თუ მას იპოვით კომენტარის გარეთ, თქვენ გაქვთ ღია-წესის აღმოჩენა. იმავე UI-ში Rules-სიმულატორი გაძლევთ თავდამსხმელის მოთხოვნის გადათამაშებას ლოკალურად — ჩასვით ანონიმური GET /users/somebody და დაამოწმეთ, რომ სიმულატორი აბრუნებს Allowed-ს.

გარე დადასტურება: გაუშვით FixVibe-სკანი თქვენი პროდუქციის URL-ის წინააღმდეგ. baas.firebase-rules შემოწმება ამოწმებს თქვენს Firestore-, Realtime Database- და Storage-წესებს და მოახსენებს იმავე აღმოჩენას, რასაც თავდამსხმელი აღმოაჩენდა — დამოუკიდებლად იმისგან, რას აჩვენებს Firebase Console.

ხშირად დასმული შეკითხვები

შემდეგი ნაბიჯები

გაუშვით FixVibe-სკანი თქვენი პროდუქციის URL-ის წინააღმდეგ — baas.firebase-rules შემოწმება ადასტურებს, ექსპლუატაციური თუ არა if true საჯარო ინტერნეტიდან. სკანერის მექანიკისთვის და პარალელური აღმოჩენებისთვის Realtime Database-ისთვის და Storage-ისთვის, ნახეთ Firebase rules სკანერი. ეკვივალენტური არასწორი კონფიგურაციის კლასისთვის Supabase-ზე, წაიკითხეთ Supabase RLS სკანერი.