Applicato nel database
Chi può leggere o modificare una riga in Fóir lo decide Postgres. Le regole sono scritte una volta, in un'unica specifica, e compilate in policy di row-level security, quindi il controllo sta con i dati, sotto il codice applicativo.
Una sola specifica, compilata
Il modello di accesso vive in un unico file di specifica. Demesne, il nostro compilatore open source, lo trasforma nelle policy e nelle funzioni del database che queste richiamano. L'SQL generato viene rilasciato esattamente come l'ha scritto il compilatore e nessuno lo modifica a mano. Al momento in cui scriviamo governa circa cento tabelle.
Forzata e verificata sullo schema reale
La row-level security è forzata su ogni tabella governata, oltre a essere abilitata, e questo chiude la via con cui il proprietario di una tabella legge oltre una policy. Un test legge entrambe le impostazioni dal catalogo del database e fallisce se una delle due è disattivata.
Un secondo test elenca ogni tabella dello schema e fallisce su quelle aggiunte senza una decisione registrata su come sono protette.
Cosa può raggiungere una richiesta
Una richiesta all'API viene servita sotto quelle policy, portando con sé workspace, progetto e organizzazione del chiamante come claim che il database legge. La policy di ogni tabella li confronta con la riga prima di considerare qualsiasi altra regola. Una riga che il chiamante non può vedere risulta come se non esistesse.
Dove decide l'applicazione
Il database non riesce a distinguere alcune azioni: pubblicare un record, per Postgres, è un aggiornamento. Quei permessi vengono verificati all'arrivo della richiesta, su una mappa generata dalla stessa specifica, e le regole sulle righe continuano a limitare ciò che l'azione può toccare.
Leggi come funziona
La documentazione copre proprietà, visibilità, grant e il modo in cui una richiesta viene risolta per ogni tipo di credenziale.