A Horizons app on Supabase fails sign-in or an RLS check

Symptom

Sign-in loops, a row-level security error appears right after signup, or the app cannot read its own Supabase tables. This is a setup failure, not a reported break-in.

Root cause

Hostinger's Supabase troubleshooting article, on the Horizons support URL, is titled for Hostinger AI Builder agentic mode. It describes authentication, database, and connection errors for projects that still use Supabase. It does not describe a breach, and it does not give a count of affected apps. Newly created projects can use the native backend; older projects can keep Supabase. The article says the usual fixes are in your own project: the Project URL and the public anon key must match the Supabase API settings, calls must go through customSupabaseClient.js rather than a second client file with placeholder values, email login must be enabled, and the preview and production URLs must be on the Supabase redirect list. If data does not load, it says to check row-level security and allow the authenticated user to read or write. An RLS error immediately after signup means the app wrote before the user was authorized, and the documented prompt moves that write to the first signed-in session. A redirect home when you return to a tab means the app checked the session before Supabase finished re-validating it. After a key or URL change, the article says to redeploy. It says not to delete extra Supabase files the builder added; undo the change that created them.

In this project only, fix the Supabase connection. Do not query or modify any other Supabase project.

1. Use customSupabaseClient.js for all Supabase calls. Remove any duplicate clients and update imports accordingly. Do not delete files by hand if the builder added them; undo the change that created the extra client.
2. Read the Project URL and the public anon key from this project's Supabase API settings. Do not print the key. Confirm the app uses those values, then tell me to redeploy.
3. In Supabase, email login should be enabled. Add this project's preview URL and production URL to Authentication, URL Configuration, Redirect URLs.
4. If a table returns an RLS error, name that table. Move initial database manipulation logic from sign up to initial sign in. Ensure all requests respect RLS and occur only after the user is authorized.
5. If the app sends people home when they return to a tab, update the Supabase logic using visibilitychange to check authentication state. Ensure the user session is fully acknowledged before any route redirection.

Do not claim this project was breached. Do not weaken a policy to USING (true) on private rows.

Paste this into the coding tool that has your own project open.

2-minute self-check

These steps are for an app you own. Do not run them against someone else's project.

1. In your own Supabase project, compare the Project URL and anon key with the values in this Horizons app. Redeploy after you change either one.
2. In Authentication, URL Configuration, confirm your own preview and production URLs are on the redirect list. Sign in on your own preview and confirm you are not sent back to the login screen.
3. Sign up a test user in your own app. If the console shows an RLS error, note the table name. After the write moves to the signed-in session, repeat the signup and confirm that user's row exists and another test user cannot read it.

Sources

• Hostinger: Fixing Supabase configuration issues