quy tắc uỷ quyền đúng cho nội dung được bảo vệ trong căn cứ hỏa lực

Question

Có một cách tiếp cận thực tiễn tốt nhất để quy tắc uỷ quyền thích hợp cho nội dung được bảo vệ trong một ứng dụng căn cứ hỏa lực

• sử dụng firepad đặc biệt
• Theo nội dung được bảo vệ tôi là nơi người dùng tạo tài liệu và chỉ chia sẻ tài liệu với một số người dùng khác).
• Ngoài ra tôi cần để có thể truy vấn căn cứ hỏa lực cho tất cả các tài liệu mà tôi có quyền truy cập vào (tài liệu mà tôi tạo ra và tài liệu người dùng khác chia sẻ với tôi)

Một số nghiên cứu của tôi cho đến nay:

Phương pháp 1: Bí mật URL

• tôi cần phải biết địa chỉ URL để có thể xem/chỉnh sửa tài liệu

• Không ủy quyền thực, vì mọi người dùng đã đăng nhập có quyền truy cập vào URL đó đều có thể chỉnh sửa/sửa đổi nó.

• Cant chỉ mục tất cả các tài liệu tôi có quyền truy cập vào

Phương pháp 2: Sử dụng quy tắc uỷ quyền căn cứ hỏa lực để thêm người dùng đến một tài liệu và kiểm tra xem người dùng là document.users trước khi đọc/ghi.

Taken từ: Protected content in Firebase possible?

{ 

"documents": { 

    "$documents_id": { 

     // any friend can read my post 

     ".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()", 

     // any friend can edit my post 
     ".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()" 

    }, 

    users:{ 

    // List of user.ids that have access to this document 

    } 

} 

} 

Ưu điểm:

• đúng phép/chứng thực. Chỉ những người dùng được xác thực đã được cấp quyền truy cập mới có thể xem/chỉnh sửa.

Nhược điểm:

• Không thể truy vấn cho tất cả các tài liệu một người dùng được phép chỉnh sửa (những người mà tôi sở hữu hoặc đã được chia sẻ với tôi) (? Là giả thiết này đúng)

Phương thức 3: Quy tắc cấp phép Firebase (phương pháp 2), cộng với một kho lưu trữ người dùng dự phòng có mảng tài liệu_ mỗi người dùng có quyền truy cập. Cửa hàng người dùng này sẽ chỉ được sử dụng để truy vấn tất cả tài liệu mà người dùng có quyền truy cập. ví dụ:

{ 
"documents": { 
    "$documents_id": { 
     // any friend can read my post 
     ".read": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()", 
     // any friend can edit my post 
     ".write": "auth.id === data.child('owner').val() || root.child('users/'+data.child.owner.val()+'/users/'+auth.id).exists()" 
    } 
}, 
"users":{ 
    "$user":{ 
     ".read": "auth.id=$user.id", 
     ".write": "auth.id=$user.id" 
     "$documents":{ 
      // All the documents i have access to. This list gets ammended whenever I am granted/stripped access to a document. 
     } 
    } 
} 
} 

Ưu điểm:

• xác thực đúng/uỷ quyền

Nhược điểm: dữ liệu

• Duplicate, phải đối phó với vấn đề đồng bộ hóa giữa hai lưu trữ dữ liệu. Điều này dường như không giống như một ý tưởng hay.

Phương pháp 4: Nhóm

Sử dụng các nhóm mỗi Granting access to Firebase locations to a group of users

• Chúng tôi có một nhóm cho mỗi tài liệu lưu trữ dữ liệu

• Cant dễ dàng truy vấn căn cứ hỏa lực cho tất cả các tài liệu người dùng có thể truy cập

Có cách nào tốt hơn để thực hiện việc này không?

Answer 1

Bạn đã hoàn thành tốt việc liệt kê các tùy chọn và bạn chắc chắn đang đi đúng hướng. Như bạn đã khám phá, không có cách nào để truy vấn dựa trên các quy tắc bảo mật. Điều này đã được thực hiện cố ý, vì (tùy thuộc vào các quy tắc bảo mật của bạn) điều này có thể khá tốn kém (Firebase tránh các truy vấn phức tạp nói chung vì lý do này).

Vì vậy, phương pháp 3 của bạn là cách chính xác để thực hiện việc này. Dữ liệu trùng lặp cho các loại tình huống này thực sự là một thực tế rất phổ biến. Xem Denormalizing Your Data is Normal để biết bài đăng trên blog có thông tin chi tiết hơn về điều này.

Bạn cũng có thể thực hiện phương pháp 1 với danh sách tài liệu trùng lặp. Điều này đặc biệt hữu ích nếu bạn muốn có thể "mời" ai đó vào một tài liệu chỉ với một URL (có chứa ID bí mật). Hoặc bạn có thể làm một sự kết hợp của hai (có một số tài liệu được "công khai nhưng không công khai" và một số là "riêng cho bạn bè được mời" hoặc bất cứ điều gì.)