Privacy-политики

До этого урока доступ к данным держался на дисциплине: хендлеры сами решали, что кому показывать, фильтры сами не забывали Where, админские операции сами проверяли роль. Каждый новый эндпоинт — новая возможность забыть проверку, а рукописный обход ent-клиента — уже не защита вовсе, как мы честно считали ещё с валидаторов третьего урока. ent privacy переворачивает ответственность: политика объявляется в схеме — там же, где поля, рёбра, хуки и интерсепторы, — и исполняется на каждой операции чтения и записи этого типа, из любого места кодовой базы, у любого собранного клиента. Это ent безопасность уровня графа: нельзя создать пользователя без viewer-а нельзя, даже если завтра коллега напишет новый сервис и забудет про роли — операция упрётся в слой, который жить в схеме, а не в хендлерах. Граница ответственности с интерсептором из восемнадцатого урока строгая: интерсептор фильтрует — прячет строки из выборок; политика решает — допускает или отменяет операцию целиком. Оба инструмента исполняются до SQL, но отвечают на разные вопросы: «что вы видите» и «можно ли вам это».

Privacy — фича-флаг генератора, как intercept из восемнадцатого урока. В ent/generate.go добавьте --feature privacy: go:generate go run -mod=mod entgo.io/ent/cmd/ent generate --feature privacy ./schema — и запустите go generate из седьмого урока. Генератор приносит пакет ent/privacy с готовым словарём: решения privacy.Allow, privacy.Deny и privacy.Skip — это sentinel-ошибки, то есть обычные error-значения, которые правила возвращают; хелперы Allowf, Denyf и Skipf — те же решения с форматированной причиной в тексте; AlwaysAllowRule и AlwaysDenyRule — правила-заглушки; ContextQueryMutationRule — фабрика правила из функции контекста; OnMutationOperation и DenyMutationOperationRule — сужение и запрет операций; DecisionContext — решение, вшитое в контекст. Второй обязательный шаг, за которым следит документация: если в схеме объявлен Policy(), в main нужен пустой импорт import _ «ваш-модуль/ent/runtime» — из-за возможного цикла импортов между схемой и пакетом ent рантайм обязан инициализироваться явно. Забудете — ent не уронит компиляцию, но первый же запрос честно откажет: user.Policy == nil, текст ошибки называет причину дословно — forgotten import ent/runtime.

ent.Policy — интерфейс из двух методов: EvalQuery(ctx, ent.Query) error — read-policy, EvalMutation(ctx, ent.Mutation) error — write-policy. В схеме вы не реализуете его руками: собираете из правил через privacy.Policy{Query: ..., Mutation: ...}, где QueryPolicy и MutationPolicy — списки правил. Правило — то же правило из мира privacy: объект с EvalQuery и/или EvalMutation, возвращающий одно из трёх решений. Решения — обычные ошибки, и семантика у них точная. privacy.Allow — «разрешить»: оценка останавливается, последующие правила не вызываются, операция допущена. privacy.Deny — «запретить»: оценка останавливается, операция отменена; любое другое возвращённое правило правило-ошибку работает как Deny. privacy.Skip — «нет мнения»: переход к следующему правилу; эквивалент возврата nil. Правила оцениваются строго в порядке объявления. И теперь честная деталь, которую надо знать про ent: если ВСЕ правила Skip — оценка завершается без ошибки, то есть операция разрешена. ent privacy не встраивает «запрещено, если не разрешено» — вы строите её сами, хвостовым правилом privacy.AlwaysDenyRule(): всё, что не пропустили предыдущие правила, отвергается. Это и есть deny по умолчанию как рабочий паттерн — и дальше в уроке он стоит в каждой политике.

Две точки исполнения, обе до всего остального. Чтение: перед исполнением выборки ent вызывает Policy.EvalQuery — раньше интерсепторов из восемнадцатого урока и раньше SQL; Count, Exist, Only и обходы рёбер проходят через ту же проверку, потому что это всё — Query-пути. Отказ — операция не исполняется вовсе: ни SELECT, ни частичных данных. Запись: политика вшивается в слот hooks[0] — самый внешний слой конвейера мутаций — и EvalMutation исполняется до всех схемных и Use-хуков из семнадцатого урока; ни один ваш хук не увидит мутацию, которую политика отвергла. Отсюда два практических следствия. Первое: privacy.Deny не обрабатывается как ValidationError или ConstraintError — это собственный sentinel, ловите errors.Is(err, privacy.Deny), и он не подменяется MaskNotFound-ом. Второе: политика и транзакции из шестнадцатого урока живут дружно — проверка исполняется на границе операции, до WithTx, и отказ не оставляет после себя открытой транзакции; внутри tx-клиента политики сработают снова, потому что tx.Client() — тот же граф, те же правила.

Privacy-список из «глобальных» правил — не единственная форма; правила можно сужать до конкретных операций мутации — знакомый приём по hook.On из семнадцатого урока. privacy.OnMutationOperation(rule, op) исполняет rule, только если m.Op().Is(op) совпал, иначе возвращает Skip — правило молчит. На нём построен готовый helper privacy.DenyMutationOperationRule(op): запрет конкретной операции с ошибкой Denyf. Вместе они закрывают классический сценарий — политику жёсткого удаления, которую четырнадцатый урок собирал из hook.Reject: там запрет жил в коде приложения и его надо было не забыть зарегистрировать, здесь — в схеме, и он работает у всех клиентов графа без исключений. Симметрия с семнадцатым уроком дословная: hook.Reject и DenyMutationOperationRule решают одну задачу на двух уровнях — рантайм и схема; если запрет обязан быть законом графа — ему место в политике. Отдельный приём для сложных правил — privacy.FilterFunc: правило получает generic-фильтр запроса и вшивает в него предикат вроде «только свой тенант», превращая доступ в ограничение выборки; это мост к мультиарендности двадцать второго урока, здесь — только знать в лицо.

Политика, как и вся защита, требует доказательств, и ent даёт для них два инструмента. Первый — privacy.DecisionContext(ctx, privacy.Allow): вшивает решение прямо в контекст, и оценка правил не запускается вовсе — операция исполняется так, будто первое правило вернуло Allow. Это способ протестировать саму логику приложения отдельно от политик: в тестах и внутренних служебных запросах — как в примере документации, где правило тенанта делает служебную выборку через DecisionContext, чтобы не зациклиться на собственной политике. Второй — errors.Is(err, privacy.Deny): отказ политики — это sentinel-ошибка, и тест обязан проверять именно её, а не текст. Рабочая матрица кейсов для политики User: контекст без viewer — Deny на мутации; viewer с ролью view — Deny на мутации, чтение разрешено; admin — всё разрешено; DecisionContext — всё разрешено без правил. Тестовый клиент — enttest.Open с SQLite, механику которого подробно разберёт двадцать третий урок (здесь упоминаем текстом): каждый кейс — три строки. И правило гигиены: политика тестируется на каждом типе схемы отдельно — наследования политик нет, mixin-политики из документации вшиваются в каждую схему как отдельные правила, и deny-хвост одной схемы не спасает соседнюю.

Вы умеете строить ent безопасность на уровне графа: privacy-фича-флаг и пакет ent/privacy, ent.Policy с EvalQuery и EvalMutation, три решения Allow/Deny/Skip и порядок их оценки, deny по умолчанию как сознательный паттерн с AlwaysDenyRule, viewer-контекст с DenyIfNoViewer и AllowIfAdmin, сужение правил OnMutationOperation и запрет операций DenyMutationOperationRule, тесты через DecisionContext и errors.Is. Политика отвечает «можно ли», но не «быстро ли»: как только доступ открыт, выборка исполняется со скоростью своих индексов — и WHERE от частичного фильтра из восемнадцатого урока, и уникальность email, и сортировка ленты упрутся в полнотабличный скан, если индексов нет. Дальше — индексы и аннотации двадцатого урока: index.Fields и Edges, составные уникальные, StorageKey, entsql-аннотации Desc, IndexType и IndexWhere — и обещанный четырнадцатым уроком частичный индекс на живых строках. Домашнее задание ниже заставит политику отказать в правильном месте и докажет это тестом. Полный план из 25 уроков — на странице курса, хуки и hook.Reject — в семнадцатом уроке, мягкое удаление — в четырнадцатом, валидаторы и граница с базой — в третьем, транзакции — в шестнадцатом.