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 ได้ที่ กฎความปลอดภัยพื้นฐาน