Sicherheit

Die App prüft Berechtigungen, damit die Oberfläche sinnvoll ist. Die Datenbank prüft sie erneut, damit sie tatsächlich gelten. Jede der folgenden Regeln wird von Postgres durchgesetzt (Row-Level-Security-Policies, Spaltenberechtigungen, Trigger oder Check-Constraints) und hat einen RLS-Test, der versucht, sie zu brechen, einschließlich Schreibvorgängen, die fehlschlagen müssen.

Sie gelten im lokalen Modus und überall sonst, wo Portline auf seiner Datenbank läuft. Der Demo-Modus hat keine Datenbank; er wendet dieselben Regeln in der App an.

1. Ihren Tarif können Sie nicht selbst bearbeiten. Tarif, Status, Nutzerplätze und Periodenende können nur von der Service-Rolle geschrieben werden. Ein Inhaber, der update pl_subscriptions set plan = 'scale' ausführt, erhält einen Fehler.
2. Gesperrte Bereiche zeigen nichts. Enthält der Tarif einen Bereich nicht, werden dessen Zeilen nicht zurückgegeben. Ein Starter-Workspace liest null Rampentermine, keine Fehlerseite mit Daten dahinter.
3. Betrachter schreiben nichts. Jeder Insert und jedes Update prüft die Stufe Bearbeiten. Ein Betrachter, der einen Rampentermin anlegt, wird abgewiesen.
4. Dokumentprüfungen erfordern Freigaberechte und werden signiert. Nur Admins und der Inhaber können ein Dokument verifizieren oder ablehnen, und die Datenbank versieht die Prüfung mit der ID des Aufrufers. Setzt ein Disponent ein Dokument auf verifiziert, schlägt das fehl; tut es ein Admin, wird reviewed_by auf diesen Admin gesetzt, egal was gesendet wurde.
5. Benachrichtigungen können nur als gelesen markiert werden. Sie können read_at für Ihre eigenen Benachrichtigungen setzen, sonst nichts. Das Umschreiben von Titel oder Link einer Benachrichtigung wird abgelehnt.
6. Das Audit-Protokoll kann weder gefälscht noch bearbeitet werden. Audit-Zeilen werden nur als Aufrufer geschrieben, und niemand kann sie aktualisieren oder löschen.
7. Niemand befördert sich selbst. Sie können Ihre eigene Rolle nicht ändern, niemand wird über die App zum Inhaber, und Admins können den Inhaber nicht verändern. Ein Disponent kann niemandes Rolle ändern.
8. Workspaces sind voneinander isoliert. Jede Policy basiert auf der Mitgliedschaft. Ein Mitglied eines Workspace liest null Zeilen eines anderen.
9. Ein abgelaufener Workspace ist schreibgeschützt. Bearbeitungen erfordern ein Abonnement mit dem Status active, trialing oder grace. Nach dem Ablauf schlägt jeder Schreibvorgang fehl.
10. Ein Fahrer kann nicht vor dem Check-in auschecken. Ein Check-Constraint verlangt eine Check-in-Zeit vor einer Check-out-Zeit, und dass der Check-out danach liegt.
11. Nachrichten werden in Ihrem Namen gepostet. Der Autor einer Nachricht muss der Aufrufer sein. Das Posten im Namen einer anderen Person schlägt fehl.

Auch in der AppVerweis auf diese Überschrift kopieren

• Jede Server-Action validiert ihre Eingabe und prüft die Berechtigungsstufe erneut, bevor sie auf Daten zugreift.
• Weiterleitungen nach der Anmeldung führen nur zu Pfaden auf derselben Website, sodass ein manipulierter ?next=-Link Sie nicht anderswohin schicken kann.
• Jede ausgehende URL, die ein Nutzer angeben könnte (Webhooks, Endpunkte von Frachtführern), durchläuft einen Guard, der Nicht-https-, private und interne Adressen ablehnt.
• Der Demo-Modus verweigert den Start in der Produktion und stellt keine ausgehenden Anfragen.