Firebase Auth & Realtime Database Apps · レッスン

ユーザーベースのアクセス制御

認証済みユーザーのIDやロールに基づいて、読み取り・書き込みアクセスを許可または拒否するルールを実装します。

「ユーザーベースのアクセス制御」はCoddyKit上の無料Firebase Auth & Realtime Database Appsレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはFirebase Auth & Realtime Database Apps学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Firebase Auth & Realtime Database Appsコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Control Access by User

Welcome to this lesson! In secure applications, it's crucial to control who can access what data. This is known as User-Based Access Control.

Firebase Realtime Database Security Rules allow you to define precise permissions based on the user who is currently logged in.

Meet the 'auth' Variable

Inside your security rules, Firebase provides a special auth variable. This variable contains information about the currently authenticated user.

auth.uid: The unique ID of the logged-in user.
auth.token: An object containing custom claims and other token details (e.g., email).

If no user is logged in, auth will be null.

Authenticated Users Only

The simplest form of user-based access is to ensure only authenticated users can read or write any data.

You can achieve this by checking if the auth variable is not null.

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

Users Read Their Own Data

Often, you want users to only read data that belongs to them. Imagine a /users node where each user has a sub-node with their UID.

We can use a wildcard variable ($uid) in the path to match the current user's ID.

{
  "rules": {
    "users": {
      "$uid": {
        ".read": "auth.uid == $uid"
      }
    }
  }
}

Users Write Their Own Data

Similarly, you can restrict write access so users can only modify their own data. This prevents one user from changing another's profile.

The rule is very similar to the read rule, just applied to .write.

{
  "rules": {
    "users": {
      "$uid": {
        ".write": "auth.uid == $uid"
      }
    }
  }
}

Read & Write Your Own Profile

Let's combine the read and write rules. This common pattern allows users full control over their own specific data node, often used for user profiles.

Here, $userId is a placeholder for an actual user's UID.

{
  "rules": {
    "profiles": {
      "$userId": {
        ".read": "auth.uid == $userId",
        ".write": "auth.uid == $userId"
      }
    }
  }
}

Post Ownership Example

Consider a 'posts' section where anyone can read posts, but only the creator can edit or delete their own post.

We assume each post object has an ownerId field. We use data.ownerId to refer to the existing owner ID in the database.

{
  "rules": {
    "posts": {
      "$postId": {
        ".read": "true",
        ".write": "auth.uid == data.ownerId"
      }
    }
  }
}

Validating Data with Auth

Beyond just who can write, you can also validate what data they write. For instance, ensuring that when a user creates an item, they correctly set themselves as the owner.

The newData variable refers to the data being written.

{
  "rules": {
    "items": {
      "$itemId": {
        ".write": "auth != null",
        ".validate": "newData.ownerId == auth.uid"
      }
    }
  }
}

Introducing User Roles

For more complex access, you can define roles like 'admin' or 'moderator'. These roles are often stored as custom claims in the user's authentication token.

You can then check for these roles in your rules using auth.token.

{
  "rules": {
    "adminContent": {
      ".read": "auth.token.isAdmin == true",
      ".write": "auth.token.isAdmin == true"
    }
  }
}

Quick Check on Access

Consider the following Realtime Database Security Rules:

{
  "rules": {
    "messages": {
      "$messageId": {
        ".read": "auth.uid == data.senderId",
        ".write": "auth.uid == data.senderId"
      }
    }
  }
}

If user "user123" is authenticated and tries to read a message where data.senderId is "user456", will they succeed?

Recap: User Access Rules

You've learned how to implement powerful user-based access control in Firebase Realtime Database Security Rules!

The auth variable provides current user details.
You can restrict access to authenticated users (auth != null).
Users can be granted read/write access to their own specific data using auth.uid == $uid.
You can validate incoming data using newData and auth.uid.
Roles can be used to grant access to specific user groups.

Next, explore how to validate the data itself!

よくある質問

「ユーザーベースのアクセス制御」レッスンは無料ですか？

はい。「ユーザーベースのアクセス制御」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Firebase Auth & Realtime Database Appsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Firebase Auth & Realtime Database Appsコースには全4レッスンが含まれています。

「ユーザーベースのアクセス制御」で何を学びますか？

認証済みユーザーのIDやロールに基づいて、読み取り・書き込みアクセスを許可または拒否するルールを実装します。ブラウザで直接実行するハンズオンコードでFirebase Auth & Realtime Database Appsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Firebase Auth & Realtime Database Appsを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのFirebase Auth & Realtime Database Appsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン2/4です。

「ユーザーベースのアクセス制御」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このFirebase Auth & Realtime Database Appsレッスンでコードを書いて実行できますか？

はい。すべてのFirebase Auth & Realtime Database Appsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Firebase Auth & Realtime Database Appsに戻る