Ich werde deinen Supabase Storage Upload 403 RLS-Fehler in 24 Stunden beheben


Über diesen Service
Automatische Übersetzung
Dein Upload gibt 403 zurück und die Nachricht sagt Row-Level Security Policy. Die Policy sieht korrekt aus. Das ist sie meistens.
Was tatsächlich passiert, ist eines von sechs Dingen: Die Anfrage kommt ohne Session an, landet als anon, das Insert wird durch WITH CHECK beurteilt und nicht USING, der Pfadpräfix stimmt nicht mit der Policy überein, Upsert und resumable Uploads brauchen auch eine UPDATE-Policy, signierte URLs benötigen SELECT, oder eine Grant unter der Policy fehlt und gibt denselben 403 zurück.
Ich finde heraus, welches es ist, behebe es und beweise es: derselbe Upload von deinem eigenen Client, vorher und nachher, mit der Antwort daneben gedruckt.
Du bekommst die Migration, eine Zeile darüber, was tatsächlich falsch war, und eine Überprüfung, was einen Fremden noch blockiert, damit die Lösung dein Bucket nicht stillschweigend für alle öffnet.
Sende mir den genauen Fehler, die Policy-SQL, den Bucket-Namen und wie dein Client erstellt wurde. Eine Staging-Kopie oder eine Read-Only-Rolle reichen aus. Ich brauche nicht deinen Service-Role-Key.
Ich baue ein Multi-Tenant-POS auf Supabase, rund 90 Migrationen, live in echten Shops. Drei Sicherheitsüberprüfungen haben sechs echte Schwachstellen gefunden, alle nach Policies, die so geschrieben waren, wie sie sind.
Lerne Basel Draz kennen
Supabase RLS and privilege audits
- AusÄgypten
- Mitglied seitFeb. 2024
- ⌀ Antwortzeit11 Stunden
Sprachen
Arabisch, Englisch
Automatische Übersetzung
Mein Portfolio
FAQ
Automatische Übersetzung
Kannst du meinen Bucket einfach öffentlich machen und fertig?
Nein. Das entfernt den Fehler, indem es die Sicherheit entfernt, und hilft auch nicht bei Uploads, da ein öffentlicher Bucket trotzdem eine INSERT-Policy braucht. Wenn der Bucket wirklich öffentlich sein soll, sage ich dir das, das dauert zwei Minuten, aber ich mache das nicht stillschweigend, um ein Ticket zu schließen.
Brauche ich meinen Service-Role-Key?
Nein, und ich würde es auch lieber nicht haben. Eine Read-Only-Rolle oder eine Staging-Kopie mit demselben Schema reichen aus, um die Ursache zu finden. Wenn ein Schreibzugriff nötig ist, schicke ich dir die Migration, die du ausführst. Du kannst alles widerrufen, was du mir gegeben hast, sobald wir fertig sind.
Ich benutze Clerk oder ein benutzerdefiniertes JWT, nicht Supabase Auth. Ändert das etwas?
Das ist abgedeckt, und es ist eine der häufigsten Ursachen. Das Claim, das deine Policy liest, ist oft nicht das Claim, das das Token tatsächlich trägt, daher kommt auth.uid() manchmal null oder falsch zurück, und jeder Upload scheitert, während der Login selbst in Ordnung aussieht.
Was, wenn sich herausstellt, dass das Problem gar nicht Storage ist?
Ich sage dir das, mit der Abfrage, die es zeigt, und du entscheidest, ob du weitermachst. Ich werde keine Storage-Findung erfinden, um die Bestellung zu rechtfertigen, und wenn hier nichts ist, was es wert ist, dafür zu bezahlen, sage ich dir das, bevor du mehr ausgibst.

