Помилка Supabase: "Unsupported provider: provider is not enabled"

Ви додаєте до застосунку кнопку "Увійти через Google" і натискаєте її. Замість вибору акаунта Google браузер показує ось це:

{"code":400,"error_code":"validation_failed","msg":"Unsupported provider: provider is not enabled"}

В адресному рядку ваш проєкт Supabase, щось на зразок https://abcdefghij.supabase.co/auth/v1/authorize?provider=google&redirect_to=…. Ви зробили застосунок у Lovable, Bolt, v0, Cursor, Claude Code чи Replit, кнопка прийшла разом із кодом, і в тому коді нічого не схоже на помилку.

"Unsupported provider: provider is not enabled" означає, що Supabase Auth, частина Supabase, яка впускає людей, має Google вимкненим у проєкті, з яким говорить ваш застосунок. Виправлення складається з одного перемикача і двох значень, які дає Google. Після цього Google перевіряє власний список, і саме з нього береться наступна помилка, redirect_uri_mismatch.

Пастка в цьому другому списку. Адреса, яка здається для нього правильною, це адреса вашого власного застосунку, і Google її ніколи не використовує, бо Google нікого до вашого застосунку не відправляє.

Що означає "Unsupported provider: provider is not enabled"?

Це означає, що Supabase відмовився починати вхід через Google, бо в проєкті, який отримав запит, Google вимкнено.

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

У вихідному коді Supabase Auth запит до /auth/v1/authorize спершу шукає провайдера, і будь-яка проблема з ним повертається як 400, з кодом validation_failed і Unsupported provider: перед причиною. provider is not enabled це перше, що перевіряє цей пошук.

Отже, Google запиту не бачив, і ніщо в консолі Google цього не пояснить. Ваш застосунок помилки теж не бачить: JavaScript-бібліотека Supabase відправляє на цю адресу весь браузер, тож сторінка, яка ламається, належить Supabase, а консоль вашого застосунку лишається порожньою.

Те саме повідомлення зʼявляється з GitHub, Apple чи будь-яким іншим вимкненим провайдером, і перемикач на тому самому місці. Застосунки на вбудованому бекенді Lovable налаштовано інакше: документація з автентифікації Lovable описує Google як "managed by Lovable with no setup, or your own Google Cloud OAuth credentials." Цей допис для застосунків на вашому власному проєкті Supabase, хоч би яким інструментом їх зроблено.

Чи це правильний проєкт Supabase?

Перевірте це, перш ніж щось змінювати, бо сторінка помилки називає проєкт, який відповів.

Адреса на сторінці помилки починається з посилання на ваш проєкт, послідовності літер перед .supabase.co. Відкрийте панель Supabase і погляньте на її власний адресний рядок: те саме посилання стоїть після /project/. Якщо вони різні, ваш застосунок говорить з іншим проєктом, наприклад тим, який для вас створив білдер, чи копією, яку ви зробили для тестів. Саме в тому проєкті й треба увімкнути Google.

Як виправити "Unsupported provider: provider is not enabled"

Створіть OAuth-клієнт у Google, а потім увімкніть Google у Supabase з двома значеннями, які він дасть. У посібнику Supabase про вхід через Google є всі кроки; ось вони в тому порядку, в якому їх просять дві консолі. Назви пунктів наведено англійською, як в обох інтерфейсах.

У Supabase спершу скопіюйте URL зворотного виклику. Перейдіть в Authentication, далі Sign In / Providers, і відкрийте Google. Там є Callback URL із кнопкою копіювання. Він має такий вигляд: https://<project-ref>.supabase.co/auth/v1/callback.

У Google Cloud створіть клієнт. На сторінці Clients у Google Auth Platform створіть OAuth client ID типу Web application.

• У Authorized JavaScript origins додайте адресу вашого застосунку, наприклад https://yourapp.com.
• У Authorized redirect URIs вставте URL зворотного виклику, скопійований у Supabase.
• Натисніть Create і одразу скопіюйте Client ID та Client Secret. Довідка Google про OAuth-клієнти попереджає: "you will only be able to view and download the full client secret once, at the time of its creation."

Поверніться в Supabase й увімкніть. Увімкніть Enable Sign in with Google, вставте Client ID у Client IDs, а секрет у Client Secret (for OAuth), і збережіть. Без Client ID панель не збереже Google увімкненим, а от із порожнім полем секрету збереже. В описі цього поля сказано, що секрет потрібен для "the OAuth flow on the web", а кнопка у вебзастосунку саме такий потік і запускає.

Потім натисніть свою кнопку ще раз. Якщо повідомлення досі починається з "Unsupported provider", його кінець підкаже, чого бракує:

Чому далі Google відповідає redirect_uri_mismatch

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

Це друга рецепція. Коли Supabase починає вхід, він передає людину до Google із запискою, куди її повернути: на URL зворотного виклику вашого проєкту. Google звіряє цю записку з Authorized redirect URIs клієнта, який ви створили. Його документація з OAuth описує збій одним рядком: "The redirect_uri passed in the authorization request does not match an authorized redirect URI for the OAuth client ID."

Збіг має бути точним. На тій самій сторінці сказано: "the http or https scheme, case, and trailing slash ('/') must all match." Тож запис, який закінчується на /auth/v1/callback/, зі скісною рискою в кінці, не збігається з адресою, яку надсилає Supabase.

Адреса вашого власного застосунку в цьому списку нічого не робить. Google повертає людей до Supabase, тож єдина адреса, яку він перевіряє, це зворотний виклик Supabase. Адреса вашого застосунку належить до списку іншої рецепції, Redirect URLs у Supabase, і саме він вирішує, куди Supabase відправить людей наприкінці. Коли цей список неправильний, люди повертаються з виконаним входом на localhost:3000, і про це є окремий допис.

Після збереження дайте Google трохи часу. Його довідка про OAuth-клієнти каже: "It may take 5 minutes to a few hours for changes made to these settings to take effect."

Де місце Client Secret

У панелі Supabase, і більше ніде. Коду вашого застосунку він не потрібен ніколи.

Client ID публічний: він їде в адресі сторінки входу Google, де його може прочитати будь-хто. Client Secret доводить Google, що запит іде з вашого боку, і в цій схемі він є лише в Supabase. Коли ваш застосунок викликає signInWithOAuth, бібліотека відправляє браузер до Supabase, і вже Supabase Auth говорить із Google, використовуючи секрет.

Тож якщо білдер поклав секрет у код вашого застосунку чи в змінну, назва якої починається з VITE_ або NEXT_PUBLIC_, він є в браузері кожного відвідувача. Ці змінні публічні за задумом. Довідка Google каже про це прямо: "Never add client secrets directly in your code or check them into version control systems such as Git or Subversion." Замініть його на сторінці клієнта в консолі Google: натисніть Add Secret, вставте новий секрет у Supabase, потім Disable для старого і видаліть його. Приберіть старе значення і з коду.

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

Як доглядати застосунок, у який тепер входять люди

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

Reeve Monitor і далі перевіряє ваш робочий застосунок:

• чи він доступний, кожні 60 секунд
• усі девʼять перевірок щогодини, до трьох застосунків, разом із секретними ключами в коді, який ваш застосунок надсилає відвідувачам
• повідомлення, коли результат змінюється, щоб ключ, який пішов із пізнішим деплоєм, дійшов до вас без того, щоб ви самі йшли дивитися
• щомісячний звіт простою мовою про те, що він бачив

Reeve Care тримає копію вашої бази даних Supabase разом з обліковими записами:

• зашифрована копія за розкладом, у власному сховищі Reeve в ЄС, поза вашим обліковим записом Supabase
• схема auth, де Supabase тримає кожного користувача й ідентичність Google, з якою він увійшов, щоб вони повернулися разом з усім іншим
• кожна копія перевірена, перш ніж зарахуватися, підрахунком рядків у кожній таблиці
• ваші вивантажені файли теж, щойно ви підключите доступ до Storage
• відновлення в один клік, із безпечною копією поточного стану, зробленою заздалегідь
• усе, що робить Monitor

Що зробити зараз

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