การควบคุมการเข้าถึงข้อมูลผู้ใช้ตามบทบาท

So far each user reads and writes their own data. Real apps need roles: an admin who moderates content, members who collaborate, and guests with read-only access.

Role-based access control (RBAC) layers permissions on top of authentication.

You can store a user's role in two places:

• A roles node in the database, read inside rules
• A custom claim on the auth token (set server-side)

Custom claims are faster to check; database roles are easier to change at runtime.

A simple model maps each uid to a role string. This data itself must be locked down so users cannot promote themselves.

Rules can read other parts of the database with root. Here only admins may write to a shared config node.

With the Admin SDK you can attach a role to the token itself. This is checked without an extra database read.

Custom claims appear under auth.token. The rule becomes simpler and avoids a root lookup.

The client can read its own claims to adjust the UI, for example showing an admin panel only to admins.

Different roles can have different read scopes. Members read shared docs; guests read only public ones.

Critically, users must not be able to edit their own role. Make the roles node writable only by admins (or only server-side), or self-escalation defeats the whole system.

After you change a custom claim, the user's existing token still has the old value until it refreshes (about an hour, or on forced refresh). Call getIdToken(true) client-side to pick up new roles immediately.

Use custom claims for stable, security-critical roles, and database roles when permissions change often or need to be queried. Many apps combine both.

You can now grant tiered access by role.

• Store roles in the database or as custom claims
• Check database roles via root, claims via auth.token
• Give roles different read/write scopes
• Lock down the role data so users cannot self-promote
• Refresh tokens to pick up new claims promptly