New row violates row-level security policy в Supabase. Що далі?

Щось підказало вам увімкнути Row Level Security. Advisor усередині вашої панелі Supabase, результат сканування, чекліст, хтось у Discord. Ви увімкнули. Тепер ваш застосунок не може зберегти взагалі нічого. Кожна спроба повертається зі словами, що a new row violates row-level security policy:

new row violates row-level security policy for table "profiles"

Ось те, що посібник за посібником переказує неправильно: відповідь, яка прибирає цю помилку за десять секунд, скасовує рівно те, що ви щойно увімкнули. Це перший результат, який ви знайдете, він діє миттєво, і він лишає таблицю точно там, де вона була до того, як вам сказали її полагодити.

Що означає "new row violates row-level security policy"

Вашу базу даних попросили зберегти рядок, вона перевірила правила тієї таблиці, не знайшла жодного, яке впускає саме цей рядок, і відмовила.

Це все повідомлення. Ніщо не пошкоджене й ніщо не втрачене: рядок так і не зберігся, а решта таблиці стоїть точно так само, як хвилину тому. Формулювання надходить від Postgres, рушія бази даних, на якому працює Supabase, і саме тому воно читається як механіка, а не як щось написане вашим білдером. Supabase передає його як є, з номером поряд, 42501.

Чого повідомлення вам не скаже, так це якого правила бракувало. Одне речення покриває три різні ситуації, і сказати вам, у якій саме ви опинилися, означало б описати ваші правила тому, хто спричинив помилку:

• Таблиця має увімкнений Row Level Security і жодного написаного правила.
• Вона має правило, і те правило лише про читання.
• Вона має правило про запис, а рядок, який ви надіслали, йому не відповідає.

Усі три друкують той самий рядок. Друга ситуація є звичною для щойно запущеного застосунку, де правило додали, щоб екрани знову працювали, а про збереження мова не заходила.

Чому вона виникла саме тоді, коли ви увімкнули Row Level Security

Бо увімкнення відмовляє всьому, доки правило не скаже інакше, а ваш власний застосунок належить до всього.

Це послідовність, яку проходить майже кожен. Ви вмикаєте налаштування. Екрани порожніють, бо без написаних правил база даних тепер не віддає рядків нікому, разом із вашим застосунком. Ви додаєте правило, щоб списки повернулися, зазвичай перше, яке підказує результат пошуку або ваш білдер. Екрани наповнюються. І першого ж разу, коли хтось натискає зберегти, зʼявляється ця помилка, у таблиці, яку ви вважали вже полагодженою.

У тій послідовності нічого не пішло не так. Правило, яке ви додали, було про читання, а збереження є іншим питанням, якого доти ніхто не ставив.

У правила дві половини, і лише одна з них про читання

Політика є умовою, а те, до чого база даних застосовує цю умову, залежить від того, про що ви її попросили.

USING застосовується до рядків, які вже лежать у таблиці. Вона вирішує, які з них вам дозволено бачити, змінювати чи прибирати. WITH CHECK застосовується до рядка, який ви намагаєтесь створити, ще до того, як він десь існує. Вона вирішує, чи цьому рядку взагалі дозволено постати.

Саме друга половина дивує людей, бо це правило про щось, чого ще немає.

Політика, написана як FOR SELECT, завжди несе лише першу половину, бо коли хтось читає, немає жодного нового рядка для перевірки. Тож вона ніколи не може дозволити збереження, хоч якою поблажливою вона виглядає. У цьому вся розбіжність, і вона пояснює, чому ваше читання відновилося, а запис ні.

Якщо ви радше подивилися б на це ззовні, наше безкоштовне сканування питає вашу базу даних наживо, що сторонній уже може з неї прочитати, без облікового запису й приблизно за 20 секунд: сканувати застосунок.

Виправлення, яке спиняє помилку, і чого воно коштує

Найшвидший спосіб її прибрати є правилом, яке дозволяє будь-який запис від будь-кого, і саме тому воно очолює майже кожен пошук.

Зазвичай воно приходить у такому вигляді:

CREATE POLICY "Enable insert for all users"
  ON public.profiles
  FOR INSERT
  WITH CHECK (true);

Кожен рядок задовольняє true, тож дозволено кожне збереження, і від вашого застосунку, і від будь-кого іншого з ключем, що їде всередині нього. Вимкнути Row Level Security назад робить те саме ще ґрунтовніше.

Обидва варіанти працюють. Обидва лишають вас там, де ви були до того, як advisor позначив таблицю, і жоден потім не показує жодної ознаки, що щось відкрите, бо ваш застосунок поводиться однаково в усіх чотирьох поєднаннях налаштування й правила. Таблиця може бути увімкненою, нести чинну політику, показувати зелений значок у вашій панелі і все одно віддавати свої рядки сторонньому. Це друга половина цієї проблеми, і її варто прочитати, перш ніж щось вставляти.

Правило, яке дозволяє зберігати вашому застосунку, і тільки йому

Назвіть, кому належить рядок, і порівняйте це з тим, хто питає:

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

auth.uid() є тим, хто увійшов і робить запит. user_id є стовпцем на рядку, який каже, кому той належить. Коли ці двоє збігаються, рядок зберігається. Коли не збігаються або коли ніхто не увійшов, у ньому відмовляють, і той, кому відмовили, бачить те саме повідомлення, на яке дивитесь ви.

Дві деталі в тому правилі заслуговують свого місця. TO authenticated означає, що правило стосується відвідувачів, які увійшли; приберіть це, і політика стосуватиметься всіх, разом зі сторонніми. І ваш застосунок має справді надсилати стовпець user_id, бо правило, яке порівнює auth.uid() зі значенням, що прийшло порожнім, ніколи не збігнеться.

Коли правило правильне, а помилка все одно зʼявляється

Подивіться, хто був у системі, перш ніж знову дивитися на політику.

Три пояснення покривають майже все, що лишається:

Ніхто не увійшов. auth.uid() повертається порожнім для відвідувача, який не входив, тож правило, що порівнює його зі стовпцем власника, збігтися не може. Це звична річ для форми реєстрації, списку очікування чи форми звʼязку, і такі форми потребують власного правила, яке описує, що дозволено додати сторонньому.

Стовпець власника так і не приходить. Ваше правило порівнює auth.uid() із user_id, а ваш застосунок надсилає все, крім user_id. Порівняння йде проти порожнечі й щоразу зазнає невдачі.

Запис іде в Storage. Завантажені файли осідають у Supabase Storage, який тримає власні політики на storage.objects, а не на вашій таблиці. Правило, написане на profiles, нічого не каже про файл.

Є четверте пояснення, і саме його варто виключити рано: якщо збереження працює з попереднього перегляду вашого білдера й не працює з живого сайту, ці двоє не користуються тим самим ключем. Таємний ключ ігнорує кожне написане вами правило, для того він і потрібен, тож застосунок, який зберігає лише поки в грі є таємний ключ, є застосунком, чиї правила ніколи по-справжньому не перевіряли. Які ключі API безпечні у вашому фронтенді показує, як відрізнити один від одного.

Що зробити сьогодні

Почніть з таблиці, з якої прийшла помилка, і перевірте кожну іншу таблицю, де ви вмикали налаштування того самого дня. 10-хвилинний чекліст безпеки охоплює те, що ще зазвичай лишається відкритим у щойно запущеному застосунку, а посібник з безпеки Supabase проходить рештою того, до чого може дістатися сторонній.