Своё действие: реестр функций и открытый эндпоинт

В статье про Server Actions модель была такой: registry.set("7f3a91", addTask), и про строку было сказано одно — её считает сборка. Посмотрим, откуда она берётся на самом деле: её выдаёт регистрация, и собрать её недолго.

Директиву "use server" легко прочитать как «перенеси код на сервер». Она делает другое: в серверном компоненте код и так на сервере. Директива регистрирует функцию — заводит ей идентификатор, кладёт её в реестр под этим идентификатором, а наружу, в разметку, отдаёт только строку. Смоделируем это функцией registerAction.

Прогноз перед запуском: что вернёт registerAction — саму функцию, обёртку над ней или что-то третье? И сколько функций окажется в реестре?

// "use server" не переносит код на сервер — он там и так. Директива
// РЕГИСТРИРУЕТ функцию: заводит ей идентификатор и кладёт в реестр,
// а наружу, в разметку, отдаёт только строку. Тело остаётся на сервере.
type Action = (fields: Record<string, string>) => string;

const registry = new Map<string, Action>();
let nextId = 1;

function registerAction(fn: Action): string {
  const id = "a" + nextId;
  nextId += 1;
  registry.set(id, fn);
  return id;
}

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

const actionId = registerAction(deleteProject);
console.log("в разметку уехало:", JSON.stringify(actionId), "| тип:", typeof actionId);
console.log("функций в реестре:", registry.size);

// «отправка» — это поиск функции по идентификатору и вызов, а не POST
const action = registry.get(actionId);
console.log(action ? action({ id: "42" }) : "нет такого действия");

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

В настоящем Next идентификатор длиннее и лежит в скрытом поле $ACTION_ID_… или в заголовке next-action, а роль реестра играет манифест действий, собранный сборщиком. Механика та же: строка снаружи, функция внутри.

Реестр из первого раздела уехал в подложку примера — вместе с зарегистрированным deleteProject и его идентификатором. Добавим серверную сторону: dispatch находит функцию по идентификатору и зовёт её. Это и есть эндпоинт — точка, куда приходит запрос.

Теперь главное. Кнопку удаления компонент рисует только администратору, а перед нами — обычный посетитель, и isAdmin у него false. Прогноз: если кнопку никто не нарисовал, сработает ли удаление?

// registry, registerAction, deleteProject и actionId — из прошлого примера.
// Добавляем серверную сторону: dispatch находит функцию по идентификатору.
// Это и есть эндпоинт — точка, куда приходит запрос
declare const actionId: string;
declare function dispatch(id: string, fields: Record<string, string>): string;

// кнопку удаления компонент рисует только админу
const isAdmin = false;
const button = isAdmin ? "<button>Удалить</button>" : null;
console.log("кнопку нарисовали:", button);

// идентификатор при этом лежит в разметке у каждого, кому страницу показали
console.log(dispatch(actionId, { id: "42" }));

Кнопки нет — null, — а проект удалён. Идентификатор лежал в разметке той страницы, где кнопку когда-то показали, и достать его оттуда ничего не стоит; dispatch же спрашивает только одно — есть ли функция под таким идентификатором. Ни про кнопку, ни про форму, ни про isAdmin он не знает вовсе: это разные места и разное время. Условие {isAdmin && …} решает, что увидит человек, а не что примет сервер.

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

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

У действия два вопроса: кто пришёл и что просит сделать. Поля fields отвечают на «что», и их пишет отправитель — любые. Ошибка в том, чтобы дать ему ответить и на «кто»: положить рядом userId и сравнить с владельцем.

Соберём канал для «кто» отдельно. Куку к запросу прикладывает браузер, но расшифровывает её сервер — и request достаёт userId из сессии сам, отдавая действию уже готовую личность. В полях места для неё нет. Прогноз: злоумышленник прислал чужую задачу t2 и дописал в поля userId: "u2" под её владельца — пройдёт ли удаление?

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

// «кто пришёл» знает только сервер: сессии живут у него, ключ к ним — кука
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: "чужая задача" }],
]);

// действие получает userId ОТДЕЛЬНЫМ параметром, а не в полях
type Action = (userId: string | null, fields: Record<string, string>) => string;

function removeTask(userId: string | null, fields: Record<string, string>): string {
  if (userId === null) return "не представились";
  const task = tasks.get(fields.taskId);
  if (task === undefined) return "нет такой задачи";
  return task.ownerId === userId ? "удалено: " + task.title : "отказано";
}

const registry = new Map<string, Action>([["a1", removeTask]]);

// транспорт: куку прикладывает браузер, а расшифровывает сервер. userId он
// достаёт из сессии САМ — в полях места для него нет
function request(id: string, cookie: string, fields: Record<string, string>): string {
  const action = registry.get(id);
  if (action === undefined) return "нет такого действия";
  const userId = sessions.get(cookie) ?? null;
  return action(userId, fields);
}

// поля подделаны: чужая задача t2 и userId под её владельца
console.log(request("a1", "cookie-рико", { taskId: "t2", userId: "u2" }));
console.log(request("a1", "cookie-рико", { taskId: "t1" }));

Первый вызов — «отказано», хотя поля выглядели согласованными. Всё дело в том, что userId в них никто не читал: request получил его из сессии по куке, а кука посетителя расшифровывается в u1. Дописанное u2 осталось мёртвым грузом — для него в действии просто нет двери. Второй вызов, где посетитель трогает свою же задачу, проходит честно.

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

В модели «кто» и «что» разведены самим устройством транспорта: у поддельного userId нет пути внутрь, потому что личность приезжает кукой, а сессию за ней заводит сервер. В настоящем Next транспорт личность в действие не подаёт — действие достаёт её само, через cookies() или вашу requireUser(), и то, что оно идёт туда, а не в formData, держится уже на дисциплине. Модель показывает, к чему эта дисциплина сводится: у личности один канал, и отправитель в него не пишет. Стоит завести запасной вход из полей — и дверь появляется.

Привязанные через bind аргументы из статьи про Server Actions — это тоже поля: они уезжают в браузер и возвращаются, их можно переписать. Поэтому в них кладут «что», а не «кто», и действие всё равно проверяет право само.

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

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

// настоящий идентификатор — не счётчик, а хеш от пути к модулю, имени
// функции и секрета сборки. Секрет свой на каждую сборку — оттого он и
// «непредсказуем»
function actionId(modulePath: string, name: string, salt: string): string {
  let h = 0;
  for (const ch of modulePath + "#" + name + "#" + salt) {
    h = (Math.imul(h, 31) + ch.charCodeAt(0)) | 0;
  }
  return (h >>> 0).toString(16);
}

// один и тот же исходник, две сборки — секрет у них разный
const build7 = actionId("app/tasks/actions.ts", "deleteProject", "K7fQ2p");
const build8 = actionId("app/tasks/actions.ts", "deleteProject", "9Zx4Mv");
console.log("сборка 7:", build7, "| сборка 8:", build8);
console.log("совпали:", build7 === build8);

// на сервере сборки 7 функция лежит в реестре под своим хешем
const registry = new Map<string, (projectId: string) => string>([
  [build7, (projectId) => "проект " + projectId + " удалён"],
]);
function dispatch(id: string, projectId: string): string {
  const action = registry.get(id);
  return action === undefined ? "нет такого действия" : action(projectId);
}

// посторонний знает путь и имя, а секрета сборки у него нет
console.log("наугад:", dispatch(actionId("app/tasks/actions.ts", "deleteProject", ""), "42"));

// а теперь идентификатор берём прямо из разметки страницы
const markup = "<input type=\"hidden\" name=\"$ACTION_ID_" + build7 + "\">";
const found = /\$ACTION_ID_([0-9a-f]+)/.exec(markup);
console.log("со страницы:", dispatch(found === null ? "" : found[1], "42"));

Сборки дали разные строки — совпали: false, — и попытка собрать идентификатор без секрета кончилась «нет такого действия»: угадать его вслепую и правда нельзя. Но последняя строка вывода закрывает вопрос. Код, который нашёл идентификатор в разметке, не знал ни секрета, ни пути, ни имени — он просто прочитал страницу, и удаление прошло.

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

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

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

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

interface Task { id: string; ownerId: string; title: string; }
type Result = { ok: true; message: string } | { ok: false; message: string };
type Action = (userId: string | null, fields: Record<string, string>) => Result;

declare const sessions: Map<string, string>;
declare const tasks: Map<string, Task>;
declare const registry: Map<string, Action>;

// действие целиком: сначала дешёвые проверки, база — потом, работа — последней
function renameTask(userId: string | null, fields: Record<string, string>): Result {
  // 1. кто пришёл — из сессии, а не из полей
  if (userId === null) return { ok: false, message: "нужно войти" };
  // 2. что прислали — разбор до всякой работы с базой
  const title = (fields.title ?? "").trim();
  if (title.length === 0 || title.length > 40) return { ok: false, message: "название: от 1 до 40 символов" };
  // 3. право — на записи из хранилища, а не на присланном
  const task = tasks.get(fields.taskId);
  // на чужое и несуществующее — один ответ, иначе чужой список просвечивает
  if (task === undefined || task.ownerId !== userId) return { ok: false, message: "задача не найдена" };
  // 4. и только теперь работа
  task.title = title;
  return { ok: true, message: "переименовано: " + task.title };
}

// транспорт кладёт куку, сервер находит действие по id и подставляет сессию
function request(id: string, cookie: string, fields: Record<string, string>): Result {
  const action = registry.get(id);
  if (action === undefined) return { ok: false, message: "нет такого действия" };
  return action(sessions.get(cookie) ?? null, fields);
}

registry.set("a1", renameTask);

// хозяин задачи t1
console.log(request("a1", "cookie-рико", { taskId: "t1", title: "купить молоко" }));
// он же на чужую t2
console.log(request("a1", "cookie-рико", { taskId: "t2", title: "переписать чужое" }));
// без куки
console.log(request("a1", "нет-куки", { taskId: "t1", title: "что угодно" }));

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