"Invalid login credentials" у Supabase: три причини

Хтось пише вам, що не може увійти у ваш застосунок, і впевнений, що пароль правильний. Ви самі пробуєте його адресу й бачите той самий червоний рядок під формою:

Invalid login credentials

Supabase відповідає "Invalid login credentials" на неправильний пароль. І рівно тими самими словами він відповідає ще двом людям: тому, чия пошта не має облікового запису у вашому застосунку, і тому, хто зареєструвався через Google і ніколи не мав пароля. Ваш застосунок із Lovable, Bolt, v0, Cursor, Claude Code або Replit працює так, як його збудовано. Він дає одну відповідь на три різні ситуації.

Ось у чому помиляється очевидне виправлення: розмите повідомлення навмисне, і якщо зробити його кориснішим, відкриється діра. Допомагає інше: зʼясувати, котрий із трьох випадків перед вами. Це може сказати ваша власна панель, а форма тим часом і далі каже так само мало, як зараз.

Що означає "Invalid login credentials" у Supabase?

Це означає, що Supabase Auth, частина Supabase, яка впускає людей, відхилила пошту й пароль і лишає причину при собі.

Повідомлення записане в коді самого сервера Auth. У функції, що обробляє вхід за паролем, та сама помилка повертається в трьох місцях: коли жоден користувач не має цієї пошти, коли в користувача не збережено пароля і коли пароль не збігається. Щоразу відповідь має статус HTTP 400 і код invalid_credentials, який довідник кодів помилок Supabase описує як "Login credentials or grant type not recognized."

У вашому застосунку вона приходить як AuthApiError від signInWithPassword, де error.code дорівнює invalid_credentials. Той самий довідник радить завжди розпізнавати помилки за error.code та error.name, і це знадобиться далі, коли ви вирішуватимете, що каже ваша форма. Якщо ваші користувачі були залогінені, а потім їх викинуло, це інша помилка, і про неї є окрема сторінка.

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

Три людини за одним повідомленням

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

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

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

Обліковий запис без пароля. Людина зареєструвалася через Google, GitHub чи іншу кнопку входу, і Supabase ніколи не зберігав для неї пароля. Коли вона повертається й вводить пароль, порівнювати нема з чим. Сервер Auth перевіряє, чи пароль збережено, перш ніж дивитися на введений, і обліковий запис без пароля отримує той самий 400.

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

Як дізнатися, котрий це був випадок?

Запитайте власну базу даних. Кожен обліковий запис у вашому проєкті є рядком у таблиці auth.users, і цей рядок каже, як людина входить.

Посібник про користувачів Supabase описує поле, яке має значення: за словами Supabase, app_metadata.providers є списком провайдерів, через які користувач може входити. Користувач може мати кілька ідентичностей, тож одна людина може мати і пароль, і Google. Чи збережено пароль узагалі, видно з колонки, яку перевіряє сам сервер.

Відкрийте SQL Editor у панелі Supabase й виконайте це з адресою, яку дала людина:

select email,
       raw_app_meta_data->'providers' as signs_in_with,
       coalesce(encrypted_password, '') <> '' as has_password,
       email_confirmed_at
from auth.users
where lower(email) = lower('person@example.com');

Запит читає один рядок і ніколи не показує пароля, лише чи він існує.

Якщо вам зручніше клацати, ніж писати, Authentication → Users у панелі показує ті самі облікові записи.

Обліковий запис, у якого ніколи не було пароля

Поверніть людину до кнопки, якою вона скористалася, або дайте їй задати пароль через ваше посилання для скидання.

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

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

Якщо людина хоче ще й пароль, ваше посилання "Забули пароль?" уже це робить. Код скидання пароля у Supabase надсилає лист для відновлення на будь-який обліковий запис, який знаходить, не перевіряючи, як його створили. Користувач Google, який перейде за посиланням і задасть новий пароль, далі зможе входити обома способами. Це залежить від того, чи є у вашому застосунку сторінка, яка задає новий пароль, тобто викликає supabase.auth.updateUser({ password }). Якщо посилання веде на сторінку, яка пароля ніколи не просить, людина один раз увійде й так і лишиться без пароля.

"Email not confirmed" означає, що пароль був правильний

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

У тій самій функції сервера Auth перевірка підтвердженої пошти йде після перевірки пароля. Отже, Email not confirmed, код email_not_confirmed, повертається лише тому, хто ввів наявну пошту і правильний пароль до неї. Довідник помилок Supabase формулює це як "Signing in is not allowed for this user as the email address is not confirmed." Біля панелі це інша лампочка: код правильний, але двері лишаються зачиненими, доки не закінчено папери про заселення.

Ви бачите його, коли для провайдера Email у вашому проєкті ввімкнено Confirm email. За посібником із налаштування Supabase, користувачі тоді мають підтвердити адресу пошти, перш ніж увійти вперше. Виправлення в листі, який людина ще не натиснула: скажіть їй перевірити вхідні й спам і запропонуйте надіслати лист ще раз через supabase.auth.resend({ type: 'signup', email }). Якщо ці листи не приходять узагалі, обмеження на надсилання листів перше, що варто виключити. Якщо листи приходять, а посилання відповідає "Email link is invalid or has expired", найімовірніше, щось відкрило його раніше за людину.

Оскільки це повідомлення зʼявляється лише після правильного пароля, прохання перевірити пошту не дає сторонньому нічого, чого він ще не мав.

Чому повідомлення лишається розмитим

Бо корисна версія розповіла б стороннім, хто ваші користувачі.

Уявіть, що панель відповідає "у квартирі 4Б ніхто не живе". Будь-хто, хто проходить повз, міг би пройтися списком квартир і дізнатися, які з них зайняті.

Ваша форма працює так само. Якби вона казала "Облікового запису з цією поштою немає", будь-хто зі списком адрес міг би вводити їх одну за одною й дізнатися, які належать вашим користувачам. Витік даних на якомусь іншому сайті лишає по собі такий список, іноді разом із паролями, якими люди там користувалися. Хто знає, які адреси належать вашим користувачам, знає, чиї старі паролі варто пробувати у вашому застосунку і хто, найімовірніше, відкриє лист, схожий на ваш.

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

На боці реєстрації є перемикач, яким керуєте ви. Вигаданий користувач повертається тоді, коли підтвердження вимагається і для реєстрацій поштою, і для реєстрацій телефоном. Якщо будь-яке з двох вимкнено (телефонне враховується, навіть коли ваш застосунок ніколи не використовує вхід за телефоном), зареєстрована адреса отримує User already registered, код user_already_exists, і ваша форма реєстрації сама стає перевіркою списків.

До того ж корисне повідомлення має звідкись узятися. Supabase не каже вашому застосунку, чи є в пошти обліковий запис, тож, щоб показати "Облікового запису з цією поштою немає", застосунок має зʼясувати це сам. Це означає пошук, який працює для відвідувача без входу: читання вашої таблиці profiles, яке вдається лише тоді, коли будь-хто може читати пошту в ній, або функція бази даних, яка шукає в auth.users для будь-кого, хто питає. Так чи інакше, список ваших користувачів стає видимим ззовні.

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

Що натомість має бути на сторінці входу

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

• Одне повідомлення на всі три випадки, простими словами, з іншими шляхами поруч: "Пошта й пароль не збігаються. Якщо ви реєструвалися через Google, скористайтеся кнопкою нижче." Воно допомагає користувачу Google і не каже сторонньому нічого, чого не каже ваша сторінка реєстрації.
• Кожен спосіб із вашої сторінки реєстрації. Кнопка Google, magic link і поле пароля, усе це й на сторінці входу.
• Посилання "Забули пароль?" на сторінку, яка його задає. Supabase там відповідає на кожну адресу однаково, тож його безпечно показувати, і так людина без пароля його отримує.
• Рішення за error.code. Показуйте своє розмите повідомлення для invalid_credentials, а "перевірте вхідні" з кнопкою повторного надсилання для email_not_confirmed. Довідник помилок Supabase радить розпізнавати помилки за кодом, а не за текстом повідомлення, і попереджає, що коди статусу HTTP можуть несподівано змінитися.

У коді це дві гілки:

const { error } = await supabase.auth.signInWithPassword({ email, password })
if (error?.code === 'email_not_confirmed') showCheckYourInbox(email)
else if (error) showSignInHelp()

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

Щоб сторінка входу лишалася такою, якою ви її залишили

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

Reeve Monitor і далі перевіряє ззовні:

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

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

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

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

Якщо проблема починається на крок раніше і нові облікові записи взагалі не створюються, Database error saving new user описує цей бік форми. 10-хвилинний чекліст безпеки охоплює те, що зазвичай лишається відкритим у щойно запущеному застосунку.