Supabase Backend as a Service · レッスン

ポリシーによるアクセス管理

Supabase Storageのポリシーを使ってファイルへのきめ細かなアクセス制御を実装し、データの安全性を確保します。

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

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

Intro to Storage Policies

Welcome! In this lesson, we'll dive into Supabase Storage Policies. These policies are your key to controlling who can access, upload, or delete files in your buckets.

Think of them as security guards for your cloud files, ensuring only authorized actions happen.

Why Storage Security Matters

Without proper policies, your files could be vulnerable. Anyone could potentially upload malicious content, or sensitive user data might be publicly exposed.

Prevent unauthorized access: Keep private files secure.
Control uploads: Ensure only legitimate users can add files.
Manage deletions: Prevent accidental or malicious file removal.

Policies are essential for building secure applications.

Enabling RLS for Buckets

Just like with database tables, Supabase Storage uses Row-Level Security (RLS) for buckets. Before you can apply any policies, RLS must be enabled for your storage bucket.

You can do this in the Supabase dashboard under 'Storage' by clicking on a bucket and toggling 'Enable RLS', or directly with SQL:

ALTER TABLE storage.buckets
  ENABLE ROW LEVEL SECURITY;

Understanding Policy Syntax

Storage policies are written using SQL, similar to database RLS. They specify what actions are allowed (SELECT, INSERT, UPDATE, DELETE) and under what conditions.

Key parts of a policy:

CREATE POLICY: Starts the policy definition.
ON storage.objects: Specifies the table policies apply to.
FOR [action]: Defines the operation (SELECT, INSERT, UPDATE, DELETE).
USING / WITH CHECK: Sets the conditions for the policy.

Policy: Public Read Access

Let's create a policy to allow anyone to read files from a specific bucket, for example, a 'public-images' bucket. This is common for assets like profile pictures or product images.

The auth.role() = 'anon' part means unauthenticated users, and auth.role() = 'authenticated' means logged-in users. We'll allow both here.

CREATE POLICY "Allow public read access"
  ON storage.objects FOR SELECT
  TO public
  USING (bucket_id = 'public-images');

Policy: Authenticated User Uploads

Now, let's create a policy that allows only authenticated users to upload files to a 'user-uploads' bucket. Crucially, we want them to only upload into a folder named after their own user ID.

We use auth.uid() to get the current user's ID and path_tokens[1] to check the first part of the file path.

CREATE POLICY "Allow authenticated user upload"
  ON storage.objects FOR INSERT
  TO authenticated
  WITH CHECK (bucket_id = 'user-uploads' AND auth.uid()::text = path_tokens[1]);

Policy: Authenticated User Read Their Own

To complement the upload policy, let's ensure authenticated users can *only* read files that they themselves own within the 'user-uploads' bucket.

This policy uses auth.uid() to match the owner of the file (which is stored in the owner column of storage.objects) and also checks the file path.

CREATE POLICY "Allow authenticated user read their own"
  ON storage.objects FOR SELECT
  TO authenticated
  USING (bucket_id = 'user-uploads' AND auth.uid() = owner);

The storage.objects Table

Storage policies operate on the hidden storage.objects table. This table stores metadata about every file in your buckets. Understanding its columns is vital for writing effective policies.

id: Unique identifier for the object.
bucket_id: The ID of the bucket the object belongs to.
name: The full path and filename.
owner: The auth.uid() of the user who uploaded the file.
path_tokens: An array of strings representing the path segments.

Policy: Admin-Only Delete

Sometimes, only specific users (like administrators) should be able to delete files. Let's create a policy that allows deletion only if the user has a specific role, for example, an 'admin' role.

This requires a custom function to check user roles, or you can simplify by checking a specific `owner` UID if only one admin account exists.

CREATE POLICY "Allow admins to delete"
  ON storage.objects FOR DELETE
  TO authenticated
  USING (bucket_id = 'sensitive-data' AND auth.jwt() ->> 'user_role' = 'admin');

Testing Policies Effectively

After creating policies, it's crucial to test them thoroughly. You can do this by:

Logging in as different users: Test with authenticated users, unauthenticated users, and users with different roles.
Attempting forbidden actions: Try to upload, read, or delete files that your policies should prevent.
Using the Supabase client: Make API calls with supabase-js or other client libraries and observe the responses (e.g., expecting 403 Forbidden errors).

Always verify your policies work as intended before deploying to production.

Quick Policy Check

You've learned how to create various Storage policies. Which of the following conditions would allow an authenticated user to insert a file into a bucket named 'private-docs' ONLY if the file is placed in a folder matching their user ID?

Recap: Storage Policies

Great job! You've learned how to secure your Supabase Storage with policies. We covered:

The importance of RLS for storage buckets.
Creating policies for various actions (read, insert, delete).
Using auth.uid() and path_tokens for granular control.
Understanding the storage.objects table.

Implementing strong storage policies is crucial for the security and integrity of your application's file management.

よくある質問

「ポリシーによるアクセス管理」レッスンは無料ですか？

はい。「ポリシーによるアクセス管理」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Supabase Backend as a Serviceコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Supabase Backend as a Serviceコースには全4レッスンが含まれています。

「ポリシーによるアクセス管理」で何を学びますか？

Supabase Storageのポリシーを使ってファイルへのきめ細かなアクセス制御を実装し、データの安全性を確保します。ブラウザで直接実行するハンズオンコードでSupabase Backend as a Serviceを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Supabase Backend as a Serviceを始めるのに経験は必要ですか？

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

「ポリシーによるアクセス管理」レッスンにはどのくらい時間がかかりますか？

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

このSupabase Backend as a Serviceレッスンでコードを書いて実行できますか？

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

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

← Supabase Backend as a Serviceに戻る