Cloud: data model, security rules, and the authorization gate

Đang mở
  • Có gì không ổn?
#789 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
38/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
firebase, typescript
Lĩnh vực
authentication, cloud, databases, security, testing-qa

Hướng nghiên cứu

Start with firestore.rules and storage.rules, then inspect the first-sign-in flow and the rules unit tests using @firebase/rules-unit-testing; review dependencies #787 and #788 first. Done means the listed data model, provisioning and authorization behavior work, all specified negative cases are covered, and scoped mutation coverage reaches at least 80%.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Summary

Define the Firestore/Storage data model and the security rules that are the entire
authorization boundary for this milestone, plus the first-sign-in provisioning flow.

Provisioning is admin-only, but requires no Cloud Function: because identity is Google-only,
"admin adds a user" is just a Firestore write to an allowlist, and the security rule decides
whether a first-time user may create their own user document.

Data model

config/defaults               { quotaBytes: 26214400, maxFiles: 2000, maxFileBytes: 5242880 }
allowlist/{lowercasedEmail}   { addedBy, addedAt, note }
allowedDomains/{domain}       { addedBy, addedAt }          // e.g. "adventuresinlua.com"

users/{uid}                   { email, displayName, role: 'user'|'admin', disabled,
                                quotaBytes, maxFiles, createdAt, lastSeenAt }
users/{uid}/drive/manifest    { entries: { "<encPath>": {s,h,b,r?} }, usedBytes, fileCount, rev }
users/{uid}/content/{encPath} { c: string }                 // text <= 256 KB
gs://.../users/{uid}/blobs/{encPath}                        // binary, or text > 256 KB

encPath is encodeURIComponent(path) — Firestore document IDs cannot contain /. Guard the
illegal . and .. document-ID cases and the 1500-byte ID limit.

Separation of authority

This is the property the whole security model rests on:

  • A user may write their own manifest and content. Rules validate those writes against limits
    read from users/{uid}.
  • A user may never write their own quotaBytes, maxFiles, role, or disabled. Those are
    admin-only, which is what keeps the admin panel a set of plain Firestore writes.
  • usedBytes and fileCount live on the manifest, not the user doc, precisely so the user
    can update them without being able to touch their own limits.

Authorization flow

  1. User completes Google sign-in (#788).
  2. Client reads users/{uid}. Exists and disabled != true -> authorized.
  3. Absent -> client attempts to create it. The rule permits creation only when
    allowlist/{lowercasedEmail} or allowedDomains/{emailDomain} exists, and pins quotaBytes,
    maxFiles, and role: 'user' to the values in config/defaults.
  4. Creation denied -> show exactly "{EMAIL} is not authorized." and call signOut().

The client-side check is a UX affordance. The security rule is the real gate. An
unauthorized person still ends up with a Firebase Auth record; rules must deny them all data.

Acceptance criteria

  • firestore.rules and storage.rules implement the model above
  • First sign-in by an allowlisted email self-provisions users/{uid} with defaults from config/defaults
  • First sign-in by an email on an allowed domain self-provisions identically
  • Unauthorized sign-in shows exactly "{EMAIL} is not authorized." and signs the user out
  • disabled: true blocks all data access
  • Admin bootstrap documented (hand-edit role: 'admin' in the console after first sign-in)
  • Rules unit tests via @firebase/rules-unit-testing cover the negative cases:
    • non-allowlisted email cannot create users/{uid}
    • email on a non-allowed domain cannot create users/{uid}
    • a user cannot raise their own quotaBytes or maxFiles
    • a user cannot set role: 'admin' on themselves
    • a user cannot read or write another uid's manifest, content, or blobs
    • a disabled user is denied
    • an unauthenticated request is denied everywhere
  • Scoped mutation coverage >= 80%

Implementation notes

  • Firestore rules can get() other documents, and Storage rules can call
    firestore.get()     — that is what lets Storage enforce per-user limits read from Firestore
    rather than trusting client input. Note each such call costs a document read.
  • Rules string functions include .split(), so the email domain can be derived in-rule from
    request.auth.token.email.
  • Because the rules are the authorization boundary, a suite of passing positive tests proves
    nothing on its own. The negative cases above are the point of this issue.

Depends on

  • #787
  • #788

Branching

This issue is part of the Cloud Accounts & Storage
milestone, which uses feat/cloud as its integration branch.

Branch from feat/cloud, and open the PR against feat/cloud. Never against main.

Create the branch (the --base flag also sets the default PR target for this branch):

gh issue develop <number> --base feat/cloud --checkout

Open the PR:

python3 scripts/issue-review.py <number> --base feat/cloud \
  --summary "<summary>" --test-plan "<test-plan>"

feat/cloud merges to main in a single PR once the milestone is complete.

Why both flags are required: gh issue develop without --base branches from the repository
default branch (main), and scripts/issue-review.py falls back to main when --base is
omitted — both for the gh pr create target and for the changed-file list in the PR body.

Ngôn ngữ chính
TypeScript
Star
1
Fork
0
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jcollard/LuaInTheWeb

Tất cả issue của jcollard/LuaInTheWeb

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.