กฎความปลอดภัยและการตรวจสอบสิทธิ์ Firebase

Firebase Security Rules มอบการควบคุมการเข้าถึงและการตรวจสอบข้อมูลในรูปแบบที่รองรับ ที่ซับซ้อนหลายระดับ เพื่อสร้างระบบการเข้าถึงตามบทบาทและผู้ใช้ ที่ทำให้ผู้ใช้ ความปลอดภัยของข้อมูล ให้ใช้ Firebase Authentication กับ Firebase Security Rules

ระบุผู้ใช้

Authentication ระบุผู้ใช้ที่ขอสิทธิ์เข้าถึงข้อมูลของคุณและระบุว่า เป็นตัวแปรที่คุณนำมาใช้ประโยชน์ในกฎของคุณได้ ตัวแปร auth มีข้อมูลต่อไปนี้

  • uid: รหัสผู้ใช้ที่ไม่ซ้ำ ที่กำหนดให้กับผู้ใช้ที่ส่งคำขอ
  • token: แผนที่ค่าที่รวบรวมโดย Authentication

ตัวแปร auth.token มีค่าต่อไปนี้

ช่อง คำอธิบาย
email อีเมลที่เชื่อมโยงกับบัญชี หากมี
email_verified true หากผู้ใช้ยืนยันแล้วว่ามีสิทธิ์เข้าถึงที่อยู่ email ผู้ให้บริการบางรายจะยืนยันอีเมลที่ตนเองเป็นเจ้าของโดยอัตโนมัติ
phone_number หมายเลขโทรศัพท์ที่เชื่อมโยงกับบัญชี หากมี
name ชื่อที่แสดงของผู้ใช้ หากตั้งค่าไว้
sub Firebase UID ของผู้ใช้ ชื่อนี้จะเป็นค่าที่ไม่ซ้ำกันภายในโปรเจ็กต์
firebase.identities พจนานุกรมของข้อมูลประจำตัวทั้งหมดที่เชื่อมโยงกับบัญชีของผู้ใช้นี้ คีย์ของพจนานุกรมสามารถเป็น email, phone, google.com, facebook.com, github.com, twitter.com ค่าของพจนานุกรมคืออาร์เรย์ของตัวระบุที่ไม่ซ้ำกันสำหรับผู้ให้บริการข้อมูลประจำตัวแต่ละรายที่เชื่อมโยงกับบัญชี ตัวอย่างเช่น auth.token.firebase.identities["google.com"][0] จะมีรหัสผู้ใช้ Google รหัสแรกที่เชื่อมโยงกับบัญชี
firebase.sign_in_provider ผู้ให้บริการการลงชื่อเข้าใช้ที่ใช้เพื่อรับโทเค็นนี้ อาจเป็นสตริงใดสตริงหนึ่งต่อไปนี้ custom, password, phone, anonymous, google.com, facebook.com, github.com, twitter.com
firebase.tenant รหัสกลุ่มผู้ใช้ที่เชื่อมโยงกับบัญชี (หากมี) เช่น tenant2-m6tyz

หากต้องการเพิ่มแอตทริบิวต์การตรวจสอบสิทธิ์ที่กำหนดเอง auth.token ยังมีการอ้างสิทธิ์ที่กำหนดเองด้วย ที่คุณระบุ

เมื่อผู้ใช้ที่ขอสิทธิ์เข้าถึงไม่ได้ลงชื่อเข้าใช้ ตัวแปร auth จะเป็น null คุณสามารถใช้ประโยชน์จากสิ่งนี้ได้ในกฎของคุณ เช่นในกรณีที่คุณต้องการจำกัดการอ่าน สิทธิ์เข้าถึงผู้ใช้ที่ตรวจสอบสิทธิ์แล้ว — auth != null แต่โดยทั่วไปเราแนะนำให้ จำกัดสิทธิ์การเขียนเพิ่มเติม

ดูข้อมูลเพิ่มเติมเกี่ยวกับตัวแปร auth ได้จากข้อมูลอ้างอิง เอกสารประกอบสำหรับ Cloud Firestore, Realtime Database และ Cloud Storage

ใช้ประโยชน์จากข้อมูลผู้ใช้ในกฎ

ในทางปฏิบัติ การใช้ข้อมูลที่ตรวจสอบสิทธิ์แล้วในกฎทำให้กฎของคุณ มีประสิทธิภาพและยืดหยุ่นมากขึ้น คุณสามารถควบคุมการเข้าถึงข้อมูลตามผู้ใช้ ตัวตน

ในกฎ ให้กำหนดวิธีที่ข้อมูลในตัวแปร auth ซึ่งก็คือค่า ข้อมูลผู้ใช้ของผู้ร้องขอ — ตรงกับข้อมูลผู้ใช้ที่เชื่อมโยงกับ ข้อมูลที่ขอ

ตัวอย่างเช่น แอปของคุณอาจต้องการให้ผู้ใช้สามารถอ่านและเขียน ข้อมูลของตัวเอง ในสถานการณ์นี้ คุณจะต้องมีการจับคู่ระหว่าง ตัวแปร auth.uid และรหัสผู้ใช้ในข้อมูลที่ขอ:

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Realtime Database

{
  "rules": {
    "users": {
      "$userId": {
        // grants write access to the owner of this user account
        // whose uid must exactly match the key ($userId)
        ".write": "$userId === auth.uid"
      }
    }
  }
}

Cloud Storage

service firebase.storage {
  // Only a user can upload their file, but anyone can view it
  match /users/{userId}/{fileName} {
    allow read;
    allow write: if request.auth != null && request.auth.uid == userId;
  }
}

ระบุข้อมูลผู้ใช้ที่กำหนดเอง

คุณสามารถใช้ประโยชน์จากตัวแปร auth เพิ่มเติมเพื่อกำหนดช่องที่กำหนดเอง กับผู้ใช้แอปของคุณ

เช่น สมมติว่าคุณต้องการสร้าง "ผู้ดูแลระบบ" บทบาทที่ให้สิทธิ์การเขียน ในบางเส้นทาง คุณต้องกำหนดแอตทริบิวต์ดังกล่าวให้กับผู้ใช้ และ จากนั้นให้ใช้ประโยชน์จากกฎในกฎที่ให้สิทธิ์เข้าถึงในเส้นทาง

ใน Cloud Firestore คุณจะสามารถเพิ่มช่องที่กำหนดเองให้กับผู้ใช้ได้ เอกสารและเรียกข้อมูล ค่าของฟิลด์นั้นด้วยการอ่านที่ฝังอยู่ในกฎของคุณ ดังนั้น การติดต่อผู้ดูแลระบบ ควรมีลักษณะดังตัวอย่างต่อไปนี้

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents/some_collection: {
    // Remember that, in Cloud Firestore, reads embedded in your rules are billed operations
    write: if request.auth != null && get(/databases/(database)/documents/users/$(request.auth.uid)).data.admin == true;
    read: if request.auth != null;
  }
}

คุณจะเข้าถึงการอ้างสิทธิ์ที่กำหนดเองได้ในRulesหลังจากสร้างการอ้างสิทธิ์ที่กำหนดเองใน Authentication จากนั้นคุณจะสามารถ อ้างอิงการอ้างสิทธิ์ที่กำหนดเองเหล่านั้นโดยใช้ตัวแปร auth.token

Cloud Firestore

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an admin claim
    allow write: if request.auth.token.admin == true;
    allow read: true;

    // Alterntatively, for role-based access, assign specific roles to users
    match /some_collection/{document} {
     allow read: if request.auth.token.reader == "true";
     allow write: if request.auth.token.writer == "true";
   }
  }
}

Realtime Database

{
  "rules": {
    "some_path/$sub_path": {
      // Create a custom claim for the admin role
      ".write": "auth.uid !== null && auth.token.writer === true"
      ".read": "auth.uid !== null"
      }
    }
  }

Cloud Storage

service firebase.storage {
  // Create a custom claim for the admin role
  match /files/{fileName} {
    allow read: if request.auth.uid != null;
    allow write: if request.auth.token.admin == true;
  }
}

ดูตัวอย่างเพิ่มเติมของ Rules พื้นฐานที่ใช้ Authentication ได้ที่ กฎความปลอดภัยพื้นฐาน