Действие — это открытый эндпоинт

В первой статье главы мы разобрали, что уходит по сети: сборка оставляет от действия строку-идентификатор, React кладёт её в форму, а отправка превращается в POST на адрес текущей страницы с этим идентификатором в заголовке next-action. Прочитайте это утверждение задом наперёд — и получится вся сегодняшняя статья. Если запрос с таким идентификатором вызывает функцию, то любой запрос с таким идентификатором вызывает функцию.

Идентификатор непредсказуем и пересчитывается между сборками — но на этом его защитные свойства кончаются. Он лежит в разметке страницы у каждого, кому эту страницу показали; достать его оттуда и повторить запрос — упражнение на десять минут. Модель ниже огрубляет всё, кроме сути: вызов приходит по идентификатору, а разметка в этом не участвует. Прогноз перед запуском: сработает ли удаление, если кнопку никто не рисовал?

// Модель того, что делает сборка: у каждого действия есть идентификатор,
// и запрос приходит по нему — разметка страницы в этом уже не участвует
type Action = (fields: Record<string, string>) => string;

function deleteProject(fields: Record<string, string>): string {
  return "проект " + fields.id + " удалён";
}

const registry = new Map<string, Action>();
registry.set("60c1a4f2", deleteProject);

// посетитель не админ, и кнопку компонент ему не нарисовал
const isAdmin = false;
console.log("кнопку показали:", isAdmin);

// а идентификатор лежал в разметке у того,
// кто эту кнопку когда-то видел
const call = registry.get("60c1a4f2");
console.log(call ? call({ id: "42" }) : "нет такого действия");

Условие {isAdmin && <DeleteButton />} из статьи про условия в разметке решает задачу интерфейса: не показывать человеку то, чем он не может воспользоваться. Задачу доступа оно не решает никак — оно вообще выполняется в другом месте и в другое время, чем действие.

Правило одной строкой: действие — не продолжение формы, а самостоятельный вход в приложение. Всё, что вы бы проверили в маршруте, написанном руками, проверяется и здесь.

У любого действия два вопроса: кто пришёл и что он просит сделать. Ошибка почти всегда одна и та же — оба ответа берут из одного места, из присланных данных. Идентификатор задачи в скрытом поле, идентификатор пользователя рядом с ним, и функция сравнивает одно с другим.

Прогноз перед запуском: обе функции получают одни и те же поля от одного и того же посетителя, и в полях указана чужая задача с её настоящим владельцем. Что ответит каждая?

interface Task {
  id: string;
  ownerId: string;
  title: string;
}

// на сервере «кто пришёл» знает только сессия: cookie расшифровывается здесь же
const sessions = new Map<string, string>([["cookie-рико", "u1"]]);
const tasks = new Map<string, Task>([
  ["t1", { id: "t1", ownerId: "u1", title: "купить хлеб" }],
  ["t2", { id: "t2", ownerId: "u2", title: "чужая задача" }],
]);

// «кто» приезжает из браузера вместе с «что» — и это единственная разница
function removeTrusting(fields: Record<string, string>): string {
  const task = tasks.get(fields.taskId);
  if (!task) return "нет такой задачи";
  return task.ownerId === fields.userId ? "удалено: " + task.title : "отказано";
}

// «кто» берётся из сессии, из аргументов приходит только «что»
function removeChecking(cookie: string, fields: Record<string, string>): string {
  const userId = sessions.get(cookie);
  if (userId === undefined) return "не представились";
  const task = tasks.get(fields.taskId);
  if (!task) return "нет такой задачи";
  return task.ownerId === userId ? "удалено: " + task.title : "отказано";
}

// скрытые поля переписаны в инспекторе: и задача чужая, и владелец под неё подогнан
const fromBrowser = { taskId: "t2", userId: "u2" };
console.log(removeTrusting(fromBrowser));
console.log(removeChecking("cookie-рико", fromBrowser));

Первая функция не сломана — она честно сравнила два числа. Беда в том, что оба числа прислал тот, у кого мы спрашиваем разрешения. Сравнение task.ownerId === fields.userId проверяет не права, а внутреннюю согласованность запроса: подставьте под чужую задачу её настоящего владельца — и проверка пройдёт.

Отсюда расстановка, которая годится для любого действия. Личность достаётся из сессии — из куки, которую расшифровывает сервер. Аргументы отвечают только на вопрос «над чем работаем». Право проверяется сравнением того, что лежит в хранилище, с тем, что сказала сессия, — и ни в одном из трёх шагов присланный «кто» не участвует.

На чужую задачу вторая функция отвечает «отказано», и это уже уступка примеру. В настоящем действии на чужое и на несуществующее лучше отвечать одинаково: разница в ответах — готовый способ перебором выяснить, какие записи у вас есть.

Второй вопрос после «кто» — «что прислали». Здесь помощь приходит откуда не ждали: типы FormData написаны честно, и компилятор возражает раньше, чем вы успеете что-то испортить. Тип у get — FormDataEntryValue | null, а сам FormDataEntryValue — это File | string.

То есть в одном значении сразу два отказа: поля может не оказаться вовсе, а может приехать файл. Прогноз: сколько диагностик даст пример и что напечатают три последние строки?

const form = new FormData();
// в браузере поле легко подменить: type="file" вместо type="text",
// и в том же имени приезжает файл
form.append("title", new Blob(["содержимое"]), "note.txt");

function saveTask(title: string): void {
  console.log("тип:", typeof title, "| длина:", title.length);
}

saveTask(form.get("title"));

saveTask(form.get("title") as string);

console.log(String(form.get("title")), String(form.get("title")).length);
console.log(String(form.get("nope")), String(form.get("nope")).length);

Диагностика одна, на первом вызове, — и после неё код всё равно выполняется: тип string в сигнатуре не мешает файлу доехать до тела функции. Два вызова saveTask напечатали одно и то же, и в этом весь урок: as string — обещание компилятору, а не проверка. Обещание оказалось ложным, и title.length вернул undefined. А String() честно превратил файл в строку "[object File]" длиной 13 символов, а отсутствующее поле — в строку "null" длиной 4.

Оба «лекарства» одинаково вредны тем, что после них проверка title.length > 0 проходит. В базу уезжает задача с названием null, а рядом в логах — ни одной ошибки.

Это ровно тот разговор, который был в части III в статье «Данные извне — это unknown». Там источником был JSON.parse, здесь — FormData, но правило одно: тип на границе не утверждают, а проверяют, и проверку пишут так, чтобы её результат видел компилятор. typeof v === "string" сужает тип; as string просто велит компилятору замолчать.

В примерах прошлых статей главы поля читались через String(formData.get("title") ?? "") — для показа механики этого достаточно, для настоящего действия мало. Разбор из следующего раздела и есть недостающая часть.

С числами всё то же самое, только незаметнее: строку в число превращает Number, и он почти никогда не жалуется. Прогноз: три формы — заполненная как надо, лишившаяся поля amount и присланная со злым умыслом. Что окажется в каждом объекте?

interface NewTask {
  title: string;
  amount: number;
}

// прямолинейное чтение полей: так пишут, когда думают о форме, а не о запросе
function readFields(form: FormData): NewTask {
  return {
    title: String(form.get("title") ?? ""),
    amount: Number(form.get("amount")),
  };
}

const honest = new FormData();
honest.append("title", "  купить хлеб  ");
honest.append("amount", "2");
console.log("честная форма:", readFields(honest));

// поля amount в запросе нет вовсе: его убрали из формы в инспекторе
const cut = new FormData();
cut.append("title", "купить хлеб");
console.log("без поля:", readFields(cut));

// а здесь количество отрицательное — в магазине это возврат денег
const hostile = new FormData();
hostile.append("title", "");
hostile.append("amount", "-3");
console.log("подделка:", readFields(hostile));

Пропавшее поле дало не NaN, а честный ноль: get вернул null, а Number(null) — это 0. Проверка Number.isNaN(amount), которую сюда обычно и дописывают, промолчит. Пустая строка и строка из одних пробелов дают тот же ноль, и защиты от отрицательного количества здесь нет никакой. Заодно посмотрите на первую строку вывода: даже честная форма привезла заголовок вместе с пробелами по краям — до базы доедут и они.

Number("0x10") — это 16, а Number("1e3") — 1000. Форма прислала строку, а не число, и как именно эта строка станет числом, решаете вы, а не отправитель.

Лечится это не россыпью if по всему действию, а одной функцией разбора: на входе FormData, на выходе — размеченное объединение из части III. Либо готовое значение нужного типа, либо причина отказа; третьего не дано, и компилятор за этим следит.

interface NewTask {
  title: string;
  amount: number;
}

type Parsed =
  | { ok: true; value: NewTask }
  | { ok: false; error: string };

function parseNewTask(form: FormData): Parsed {
  const title = form.get("title");
  // typeof отсеивает разом и null, и File: ниже title — точно строка
  if (typeof title !== "string") return { ok: false, error: "заголовок не пришёл строкой" };

  const trimmed = title.trim();
  if (trimmed.length === 0 || trimmed.length > 40) {
    return { ok: false, error: "заголовок: от 1 до 40 символов" };
  }

  const raw = form.get("amount");
  if (typeof raw !== "string") return { ok: false, error: "количество не пришло" };
  const amount = Number(raw);
  // одна проверка отбрасывает сразу NaN, 2.5 и Infinity
  if (!Number.isInteger(amount) || amount < 1 || amount > 99) {
    return { ok: false, error: "количество: целое от 1 до 99" };
  }

  return { ok: true, value: { title: trimmed, amount } };
}

function report(name: string, form: FormData): void {
  const parsed = parseNewTask(form);
  console.log(name, parsed.ok ? parsed.value : parsed.error);
}

const honest = new FormData();
honest.append("title", "  купить хлеб  ");
honest.append("amount", "2");
report("честная форма:", honest);

const cut = new FormData();
cut.append("title", "купить хлеб");
report("без поля:", cut);

const hostile = new FormData();
hostile.append("title", "");
hostile.append("amount", "-3");
report("подделка:", hostile);

Заодно решилась задача из второй статьи главы: parsed.ok === false — это уже готовое состояние формы, которое действие возвращает через useActionState, и текст отказа в нём лежит рядом с меткой. Проверка на сервере и сообщение читателю получаются из одного разбора, а не пишутся дважды.

И оговорка про парность проверок. Браузерная проверка не бесполезна — она нужна, но занята другим делом.

Про вход мы договорились. Осталась вторая половина границы: то, что действие возвращает, тоже пересекает сеть и попадает в браузер — а через useActionState ещё и оседает в состоянии формы. Вернуть из действия строку, которую вернула база, — значит отправить её читателю целиком.

Прогноз: тип обещает два поля, а функция отдаёт объект из четырёх. Что скажет компилятор и что окажется в выводе?

interface UserRow {
  id: string;
  name: string;
  email: string;
  passwordHash: string;
}

interface PublicUser {
  id: string;
  name: string;
}

// то, что вернул бы запрос к базе, — строка целиком
function findUser(): UserRow {
  return { id: "u1", name: "Рико", email: "rico@example.com", passwordHash: "$2b$10$K7f" };
}

// действие обещает отдать наружу только публичные поля
async function loadProfile(): Promise<PublicUser> {
  return findUser();
}

void loadProfile().then((profile) => {
  console.log(JSON.stringify(profile));
});

Компилятор промолчал — и был прав по своим правилам. Типизация в TypeScript структурная: объект с четырьмя полями подходит везде, где ждут объект с двумя, потому что нужные два у него есть. Про лишние поля компилятор ругается только на свежих литералах — это разбиралось в части III. Здесь литерала нет, есть возвращённое значение функции, и оно проходит молча вместе с хешем пароля.

Тип, который «сужает» ответ, ничего не срезает: типы стираются на сборке, а в браузер едет обычный объект. Срезать поля должен код — и вот тут строгость к литералам работает уже на вас.

interface UserRow {
  id: string;
  name: string;
  passwordHash: string;
}

interface PublicUser {
  id: string;
  name: string;
}

function findUser(): UserRow {
  return { id: "u1", name: "Рико", passwordHash: "$2b$10$K7f" };
}

// ответ собирается руками, поле за полем: наружу едет ровно перечисленное
async function loadProfile(): Promise<PublicUser> {
  const user = findUser();
  return { id: user.id, name: user.name };
}

const leaked: PublicUser = { id: "u2", name: "Гость", passwordHash: "$2b$10$K7f" };
console.log(leaked.name);

void loadProfile().then((profile) => {
  console.log(JSON.stringify(profile));
});

Диагностика на последнем объявлении — та самая проверка лишних свойств: «объектный литерал может использовать только известные свойства». Она и есть причина писать отображение руками: пока ответ собирается из полей по одному, любое лишнее поле в нём — ошибка сборки, а не тихая утечка.

Тот же разговор про тексты ошибок. Во второй статье главы мы договорились ошибку возвращать, а не бросать; здесь добавляется, что возвращать нужно свой текст, а не сообщение исключения: в нём легко приезжают имена таблиц, куски запроса и путь к файлу на сервере.

Всё сказанное складывается в один порядок, и порядок этот не случайный: сначала дешёвые проверки, потом обращения к базе, работа — последней. Сессия не подтвердилась — не надо разбирать поля. Поля не разобрались — не надо ходить в базу.

// В проекте первые строки — импорты: cookies из "next/headers",
// revalidatePath из "next/cache", доступ к базе. Песочница выполняет
// один файл, поэтому здесь они только объявлены
"use server";

interface Session {
  userId: string;
  role: "user" | "admin";
}
interface Task {
  id: string;
  ownerId: string;
}
type Result = { status: "ok" } | { status: "error"; message: string };

declare function currentSession(): Promise<Session | null>;
declare function findTask(id: string): Promise<Task | null>;
declare function renameTask(id: string, title: string): Promise<void>;
declare function revalidatePath(path: string): void;

// подпись как у действия из useActionState: предыдущее состояние и поля формы
async function renameAction(prev: Result, form: FormData): Promise<Result> {
  // 1. Кто пришёл — из сессии, а не из аргументов
  const session = await currentSession();
  if (session === null) return { status: "error", message: "нужно войти" };

  // 2. Что прислали — разбор до всякой работы с базой
  const id = form.get("id");
  const title = form.get("title");
  if (typeof id !== "string" || typeof title !== "string") {
    return { status: "error", message: "форма пришла неполной" };
  }
  const trimmed = title.trim();
  if (trimmed.length === 0 || trimmed.length > 40) {
    return { status: "error", message: "название: от 1 до 40 символов" };
  }

  // 3. Имеет ли право — проверяется на записи из базы, а не на том,
  //    что приехало вместе с формой
  const task = await findTask(id);
  if (task === null) return { status: "error", message: "задача не найдена" };
  if (task.ownerId !== session.userId && session.role !== "admin") {
    // тот же текст, что и у ненайденной: иначе чужой список
    // просвечивает через разницу ответов
    return { status: "error", message: "задача не найдена" };
  }

  // 4. И только теперь — работа
  await renameTask(task.id, trimmed);
  revalidatePath("/tasks");
  return { status: "ok" };
}

Пример ничего не печатает, и так задумано: сервера у песочницы нет, объявленных функций тоже. Проверяемо здесь другое — что каркас проходит через компилятор со strict: true и что типы в нём сходятся.

Двадцать строк обвязки на одно переименование выглядят избыточно ровно до первого раза, когда их не написали. В настоящем проекте первые два шага уезжают в общую функцию вроде requireUser(), а третий — в правило доступа рядом с моделью данных; в самом действии остаётся четыре вызова и работа. Но исчезнуть из действия эти шаги не могут: другого места, где запрос впервые встречается с вашими данными, у него нет.