Настройка RLS в Supabase для Android приложений

Чтобы обеспечить, чтобы пользователи могли читать и изменять только свои собственные данные в Supabase, необходимо настроить Row Level Security (RLS) для таблицы tasks. Это гарантирует, что каждый пользователь видит и может редактировать только свои собственные записи, без необходимости передавать user_id в каждую функцию или добавлять условие where tasks.user_id = user_id вручную. Supabase автоматически передает аутентификационный контекст через JWT-токен, позволяя использовать auth.uid() для идентификации текущего пользователя в политиках безопасности.

Содержание

• Введение в Row Level Security в Supabase
• Базовая настройка RLS для таблицы tasks
• Создание политик безопасности для разных операций
• Использование auth.uid() для ограничения доступа
• RPC функции и аутентификационный контекст
• Практическая реализация для Android приложения
• Источники
• Заключение

Введение в Row Level Security в Supabase

Row Level Security (RLS) — это мощная функция PostgreSQL, которая позволяет контролировать доступ к строкам данных на основе различных условий. В контексте Supabase и Android приложений, RLS становится ключевым инструментом для обеспечения безопасности пользовательских данных. Когда вы создаете мобильное приложение с использованием Supabase, важно, чтобы каждый пользователь мог видеть и изменять только свои собственные данные, а не данные других пользователей.

Почему это важно? Представьте, что ваше приложение — это список дел. Если один пользователь сможет видеть задачи других пользователей, это нарушит конфиденциальность и доверие к вашему приложению. RLS решает эту проблему автоматически на уровне базы данных, гарантируя, что даже если злоумышленник попытается выполнить прямой SQL-запрос, он увидит только свои собственные данные.

Supabase упрощает настройку RLS через интуитивно понятные SQL-команды и автоматическое управление ролями. Вместо того чтобы писать сложную логику в вашем Android коде, вы определяете политики безопасности прямо в базе данных, что делает ваше приложение более надежным и проще в обслуживании.

Базовая настройка RLS для таблицы tasks

Для начала работы с RLS в таблице tasks необходимо выполнить несколько базовых шагов. Предположим, у вас уже есть таблица tasks со следующей структурой:

CREATE TABLE tasks (
 id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
 user_id uuid NOT NULL,
 title text NOT NULL,
 description text,
 completed boolean DEFAULT false,
 created_at timestamp with time zone DEFAULT now()
);

Первым шагом включаем Row Level Security для таблицы tasks:

ALTER TABLE tasks ENABLE ROW LEVEL SECURITY;

Эта команда активирует механизм RLS для таблицы. Теперь все операции с таблицей будут проверяться через политики безопасности, которые мы определим.

После включения RLS необходимо предоставить права доступа для аутентифицированных пользователей. Для этого используем следующую команду:

GRANT SELECT, INSERT, UPDATE, DELETE ON tasks TO authenticated;

Эта команда дает пользователям с ролью “authenticated” базовые права на выполнение операций с таблицей tasks. Однако без политик безопасности эти права позволят пользователям видеть и изменять все данные в таблице, что нам не нужно.

Теперь, когда базовая настройка завершена, мы можем переходить к созданию конкретных политик безопасности, которые гарантируют, что каждый пользователь сможет работать только со своими собственными задачами.

Создание политик безопасности — это сердце системы контроля доступа. Мы определим отдельные политики для каждой операции (SELECT, INSERT, UPDATE, DELETE), чтобы обеспечить точный контроль над тем, что пользователи могут делать с данными.

Создание политик безопасности для разных операций

Для обеспечения безопасности в Android приложении с Supabase необходимо создать отдельные политики для каждой операции с таблицей tasks. Давайте рассмотрим каждую операцию подробно.

Для операции SELECT (чтение данных) создаем политику:

CREATE POLICY "Users can view their own tasks" ON tasks 
FOR SELECT TO authenticated 
USING (auth.uid() = user_id);

Эта политика гарантирует, что аутентифицированные пользователи могут видеть только те задачи, у которых user_id совпадает с их идентификатором из JWT-токена.

Для операции INSERT (добавление данных) создаем политику:

CREATE POLICY "Users can insert their own tasks" ON tasks 
FOR INSERT TO authenticated 
WITH CHECK (auth.uid() = user_id);

Эта политика проверяет, что при добавлении новой задачи ее user_id будет соответствовать ID текущего пользователя.

Для операции UPDATE (обновление данных) создаем две политики:

CREATE POLICY "Users can update their own tasks" ON tasks 
FOR UPDATE TO authenticated 
USING (auth.uid() = user_id) 
WITH CHECK (auth.uid() = user_id);

Здесь мы используем два условия:

• USING проверяет, может ли пользователь обновлять существующие строки
• WITH CHECK гарантирует, что при обновлении записи ее user_id не может быть изменен

Для операции DELETE (удаление данных) создаем политику:

CREATE POLICY "Users can delete their own tasks" ON tasks 
FOR DELETE TO authenticated 
USING (auth.uid() = user_id);

Эта политика позволяет пользователям удалять только свои собственные задачи.

После создания этих политик система безопасности полностью настроена. Теперь, когда ваш Android приложение делает запросы к таблице tasks, Supabase автоматически применяет соответствующие политики, гарантируя, что каждый пользователь работает только со своими данными.

Но как именно работает механизм auth.uid()? Давайте рассмотрим это подробнее.

Использование auth.uid() для ограничения доступа

Функция auth.uid() является ключевой в системе безопасности Supabase. Эта функция возвращает идентификатор текущего пользователя из JWT-токена, который автоматически передается с каждым запросом к базе данных.

Когда пользователь аутентифицируется в вашем Android приложении через Supabase Auth, ему выдается JWT-токен. Этот токен содержит информацию о пользователе, включая его уникальный ID. При выполнении запросов к базе данных Supabase автоматически добавляет этот токен в заголовок Authorization.

Функция auth.uid() извлекает ID пользователя из этого JWT-токена и позволяет использовать его в политиках безопасности. Это означает, что вам не нужно вручную передавать user_id в каждый запрос или проверять его в коде Android — все происходит автоматически на уровне базы данных.

Вот как это работает на практике:

1. Пользователь входит в приложение через Supabase Auth
2. Supabase Auth генерирует JWT-токен с информацией о пользователе
3. Когда приложение делает запрос к таблице tasks, Supabase автоматически добавляет JWT-токен в запрос
4. При выполнении политик безопасности функция auth.uid() возвращает ID пользователя из токена
5. Сравнение auth.uid() = user_id в политике гарантирует, что пользователь может работать только со своими данными

Этот подход имеет несколько важных преимуществ:

• Безопасность: Логика безопасности реализуется на уровне базы данных, что делает ее более надежной
• Простота: Вам не нужно передавать user_id в каждый запрос из Android приложения
• Масштабируемость: Система работает независимо от количества пользователей
• Гибкость: Вы можете использовать auth.uid() в сложных политиках безопасности

Но что насчет RPC функций? Давайте рассмотрим, как аутентификационный контекст работает при вызове функций через RPC.

RPC функции и аутентификационный контекст

При работе с RPC (Remote Procedure Call) функциями в Supabase механизм передачи аутентификационного контента работает аналогично обычным запросам к таблицам. Когда ваше Android приложение вызывает RPC функцию, Supabase автоматически передает JWT-токен текущего пользователя.

Вот как это выглядит на практике. Предположим, у вас есть функция для получения задач пользователя:

CREATE OR REPLACE FUNCTION get_user_tasks()
RETURNS TABLE (
 id bigint,
 title text,
 description text,
 completed boolean,
 created_at timestamp with time zone
) AS $$
BEGIN
 RETURN QUERY SELECT id, title, description, completed, created_at 
 FROM tasks 
 WHERE user_id = auth.uid();
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

Обратите внимание на несколько важных моментов:

1. В этой функции мы используем auth.uid() для фильтрации задач текущего пользователя
2. Нет необходимости передавать user_id как параметр — он автоматически доступен через auth.uid()
3. Ключевое слово SECURITY DEFINER позволяет функции выполняться с привилегиями владельца таблицы, что полезно для сложных операций

При вызове этой функции из Android приложения:

supabase.rpc("get_user_tasks") {
 // никаких параметров user_id не нужно передавать
}.decodeAs<List<Task>>()

Supabase автоматически добавит JWT-токен текущего пользователя в запрос, и функция получит правильный user_id через auth.uid().

Если вам нужно более сложное взаимодействие с аутентификационным контекстом, вы можете использовать auth.jwt() для доступа ко всем полям JWT токена:

CREATE OR REPLACE FUNCTION get_user_profile()
RETURNS TABLE (
 id uuid,
 email text,
 created_at timestamp with time zone
) AS $$
BEGIN
 RETURN QUERY SELECT 
 auth.jwt()->>'sub' as id,
 auth.jwt()->>'email' as email,
 auth.jwt()->>'created_at' as created_at
 FROM auth.users
 WHERE auth.jwt()->>'sub' = auth.uid();
END;
$$ LANGUAGE plpgsql;

Эта функция показывает, как получить доступ к различным полям JWT токена через auth.jwt()->>'field_name'.

Таким образом, при работе с RPC функциями вам не нужно:

• Передавать user_id как параметр
• Проверять аутентификацию в коде Android
• Беспокоиться о безопасности — все обрабатывается на уровне базы данных

Теперь давайте рассмотрим практическую реализацию для Android приложения.

Практическая реализация для Android приложения

При работе с Supabase и RLS в Android приложении ваша основная задача — правильно настроить клиент Supabase и убедиться, что все запросы выполняются через аутентифицированные сессии. Вот как это реализовать на практике.

Сначала настройте клиент Supabase в вашем Android приложении:

val supabase = createSupabaseClient(
 supabaseUrl = "https://your-project.supabase.co",
 supabaseKey = "your-anon-key"
) {
 install(Auth)
 install(Postgres)
}

Для работы с задачами создайте репозиторий или сервис:

class TaskRepository(private val supabase: SupabaseClient) {
 private val tasks = supabase.from("tasks").select()
 
 suspend fun getTasks(): List<Task> {
 // Supabase автоматически применит политики RLS
 return tasks.decodeAs<List<Task>>()
 }
 
 suspend fun insertTask(task: Task): Task {
 return tasks.insert(task).decodeAs<Task>()
 }
 
 suspend fun updateTask(id: Long, task: Task): Task {
 return tasks.update(task) { filter { Tasks::id eq id } }.decodeAs<Task>()
 }
 
 suspend fun deleteTask(id: Long) {
 tasks.delete { filter { Tasks::id eq id } }
 }
}

Важно отметить, что в этом коде нет никаких проверок user_id — они автоматически применяются на уровне базы данных через политики RLS.

Для аутентификации пользователей используйте стандартные методы Supabase Auth:

// Регистрация пользователя
supabase.auth.signUpWith(Email) {
 email = "user@example.com"
 password = "password123"
}

// Вход пользователя
supabase.auth.signInWith(Email) {
 email = "user@example.com"
 password = "password123"
}

// Получение текущего пользователя
val currentUser = supabase.auth.currentUser

После аутентификации все запросы к базе данных будут автоматически содержать JWT-токен, что гарантирует, что политики RLS будут работать правильно.

Если вам нужно использовать RPC функции, как мы обсуждали ранее, вызовы будут выглядеть так:

// Вызов RPC функции без параметров user_id
val userTasks = supabase.rpc("get_user_tasks") {
 decodeAs<List<Task>>()
}

Этот подход обеспечивает безопасность на нескольких уровнях:

• Аутентификация пользователей через Supabase Auth
• Контроль доступа на уровне базы данных через RLS
• Автоматическая передача аутентификационного контекста через JWT-токены

Теперь давайте рассмотрим источники информации, которые мы использовали при создании этого руководства.

Источники

1. Supabase Documentation on Row Level Security — Официальная документация по настройке RLS в Supabase: https://supabase.com/docs/guides/database/postgres/row-level-security
2. Supabase Auth JWT Documentation — Информация о работе с аутентификационными токенами и контекстом: https://supabase.com/docs/guides/auth/auth-helpers/auth-jwt
3. Supabase Android Client Documentation — Руководство по интеграции Supabase с Android приложениями: https://supabase.com/docs/guides/getting-started

Заключение

Настройка Row Level Security в Supabase для Android приложений — это мощный и эффективный способ обеспечения безопасности пользовательских данных. Как мы рассмотрели, вам не нужно передавать user_id в каждую функцию или добавлять условия where вручную — все это обрабатывается автоматически на уровне базы данных.

Ключевые моменты, которые нужно запомнить:

1. Включите RLS для таблицы tasks с помощью ALTER TABLE tasks ENABLE ROW LEVEL SECURITY
2. Создайте политики для каждой операции (SELECT, INSERT, UPDATE, DELETE) с использованием auth.uid()
3. Предоставьте права доступа для аутентифицированных пользователей через GRANT
4. Используйте auth.uid() в политиках безопасности для идентификации текущего пользователя
5. В RPC функциях нет необходимости передавать user_id как параметр — используйте auth.uid()

Этот подход обеспечивает безопасность на уровне базы данных, упрощает код Android приложения и делает его более надежным и масштабируемым. Ваше приложение будет гарантированно защищено от несанкционированного доступа к данным пользователей.