Aplicarea permisiunilor multi-organizație în API

Orice produs multi-organizație este la o interogare distanță de un incident. Nu unul spectaculos: nicio alarmă nu sună când o listă are patru rânduri acolo unde trebuiau trei. Clientul vede un nume pe care îl recunoaște sau o înregistrare pe care nu ar trebui să o aibă, iar încrederea s-a dus înainte ca cineva să citească vreun jurnal.

Apartenența nu este o coloană adăugată mai târziu

Varianta tentantă adaugă un identificator de organizație la tabelele care au vizibil nevoie de el și lasă aplicația să filtreze după el. Ține până la prima îmbinare care uită, până la primul raport scris în grabă, până la prima sarcină de fundal care rulează în numele nimănui.

Varianta care rezistă tratează organizația ca parte din calea de acces, nu ca pe un atribut. Fiecare citire pornește de la organizație și coboară. O interogare care nu își poate numi organizația nu rulează. Constrângerea este enervantă în prima zi și portantă în a patru suta.

Trei întrebări la care fiecare cerere trebuie să răspundă

Înainte ca o cerere să ajungă la date, trei răspunsuri trebuie să existe deja.

• În care organizație acționează cererea aceasta? Nu cea de care aparține de obicei utilizatorul, cea pe care o numește cererea.
• Ce rol are apelantul în organizația aceea? Rolurile sunt pe organizație, deci o persoană poate administra una și doar citi alta.
• Înregistrarea vizată este chiar în organizația aceea? Verificarea se face pe rând, la fel ca pe colecție, pentru că identificatorul a venit de la client.

Unde stă verificarea

La granița API-ului, înaintea stratului de date, și niciodată doar în interfață.

Un buton ascuns nu este o permisiune. Este un indiciu despre una, randat de cod care rulează pe o mașină pe care nimeni nu o controlează, într-un browser în care uneltele de dezvoltare sunt la o tastă distanță. Interfața trebuie să citească starea permisiunilor și să o reflecte. Nu trebuie niciodată să o decidă.

Verificarea la graniță face și testarea ieftină. O regulă care trăiește într-o componentă are nevoie de un browser și de o pagină randată. Aceeași regulă în spatele unui punct de API are nevoie de o cerere.

Testați regulile, nu ecranele

Testele care contează sunt scurte și plictisitoare: pentru fiecare rol și fiecare punct de API, verificați ce se întâmplă când înregistrarea aparține altei organizații. Răspunsul așteptat este aproape întotdeauna același, ceea ce face suita ușor de ținut completă.

Două obiceiuri o țin cinstită. Scrieți întâi cazul negativ, pentru că un test care demonstrează doar drumul fericit nu demonstrează nimic despre izolare. Și faceți din testele de permisiuni pe cele care blochează o îmbinare, ca o scurgere să pice build-ul în loc să ajungă în producție și apoi la un client.

Migrarea la care nu se gândește nimeni

La un moment dat un client va cere să fie împărțit în două, sau doi clienți vor fuziona, sau un utilizator va avea nevoie de acces la o a doua organizație. Dacă apartenența este o coloană, toate trei sunt reparații de date cu un fișier de calcul și respirația ținută.

Dacă apartenența este o înregistrare de sine stătătoare, cu un rol atașat perechii utilizator și organizație, toate trei sunt scrieri obișnuite. Modelul acesta costă un tabel în plus la început și nu a fost niciodată lucrul pe care să îl regretăm.