Fiecare site are un răspuns la întrebarea „cine poate schimba asta?”. Pe multe site-uri răspunsul e „toți cei cu un login”, la care s-a ajuns nu prin decizie, ci prin acumulare: conturi create pentru o lansare, permisiuni acordate ca să deblocheze pe cineva într-o vineri, un login de administrator partajat pe care un coleg plecat încă îl știe. Site-ul funcționează, așa că nimeni nu mai revine asupra lui. Articolul e despre proiectarea deliberată a acelui răspuns, astfel încât oamenii care îți editează site-ul să aibă exact accesul de care au nevoie, și ca atunci când ceva se schimbă să poți spune cine a făcut-o și când.
Rolurile sunt fișe de post
Sistemul de permisiuni din Drupal e construit în jurul rolurilor: pachete de permisiuni cu nume, atribuite oamenilor. Greșeala de proiectare e să te gândești la roluri tehnic, ca la liste de bife. Felul util de a le gândi e ca fișe de post. Ce face, de fapt, un editor de conținut pe acest site? Creează și editează articole și pagini, încarcă imagini, salvează ciorne. Ce nu are nevoie să facă niciodată? Să schimbe configurația site-ului, să instaleze module, să administreze conturile altora. Un rol scris pornind de la acea descriere acordă prima listă și nimic din a doua.
Cele mai multe organizații au nevoie de surprinzător de puține roluri. Un set tipic e un editor care creează și editează conținut, un publicist care îl poate și pune live, un administrator de site care se ocupă de meniuri, taxonomii și conturile altora, și un administrator, deținut de foarte puțini, care poate face orice. Site-urile specializate adaugă roluri pentru conținut specific: un manager de magazin pentru produse și comenzi, un agent de suport pentru tichete, un traducător pentru o limbă. Testul pentru adăugarea unui rol e dacă un grup real de oameni are un set distinct de sarcini. Dacă nu, rolurile existente sunt suficiente.
Privilegiul minim, în practică
Principiul e că fiecare persoană deține accesul minim care îi permite să-și facă treaba. În practică, asta are trei părți.
Întâi, rolurile în sine sunt minimale, ca mai sus. Apoi, oamenii dețin rolurile de care are nevoie postul lor curent, iar rolurile se schimbă când se schimbă postul: stagiarul devenit manager de marketing n-ar trebui să aibă în continuare rolul de stagiar plus alte trei. În al treilea rând, accesul puternic e temporar acolo unde poate fi. Cineva care are nevoie de acces de administrator pentru o sarcină anume îl poate primi pentru o după-amiază și îl poate pierde după, ceea ce e mult mai sigur decât o acordare permanentă de care uită toată lumea.
Drupal susține bine asta, pentru că rolurile sunt configurație: exportată, versionată și livrată împreună cu restul site-ului. O schimbare a ceea ce poate face un editor e verificată ca o schimbare de cod, testată pe staging și lansată. Permisiunile nu mai alunecă, pentru că nu se pot schimba fără să lase o urmă.
Control la nivel de câmp și de conținut
Rolurile decid capabilități largi. Unele site-uri au nevoie de un control mai fin: un editor care poate schimba corpul unui articol, dar nu data publicării, un manager regional care poate edita doar paginile din regiunea lui, un partener care își vede propriile documente și pe ale nimănui altcuiva. Drupal le tratează pe toate prin permisiuni la nivel de câmp, reguli de acces la conținut și, unde e nevoie, mici verificări de acces personalizate care rulează la fiecare cerere. Pentru că platforma le aplică centralizat, o regulă se aplică oriunde apare conținutul: în interfața editorială, în listări, în rezultatele căutării și în răspunsurile API. Nu există nicio cale de ocolire.
E același mecanism care face practice portalurile și zonele de membri. Site-ul public și aplicația privată împart un singur sistem de permisiuni, iar o regulă scrisă o dată se ține în amândouă.
Cine a schimbat ce, și când
Permisiunile decid ce pot face oamenii. Jurnalele de audit înregistrează ce au făcut. Drupal păstrează o revizie a fiecărei bucăți de conținut la fiecare salvare, cu autorul și ora, astfel că orice pagină poate fi comparată cu orice versiune anterioară și restaurată la ea. Extindem asta la configurație: fiecare schimbare a setărilor site-ului, a rolurilor, a tipurilor de conținut și a listărilor e exportată și consemnată, astfel că istoricul formei site-ului e la fel de complet ca istoricul conținutului. Și înregistrăm acțiunile administrative care ies din ambele categorii, cum ar fi autentificările, schimbările de roluri și crearea de conturi, în jurnale stocate în afara site-ului.
Jurnalele de audit sunt rar necesare și enorm de valoroase când sunt. Răspund la „de ce spune pagina asta așa?” într-un minut. Transformă „cineva a schimbat meniul” într-un nume și o oră, fără acuzații, pentru că răspunsul e de obicei o persoană rezonabilă care a făcut ceva rezonabil despre care nimeni altcineva nu știa. Și sunt ceea ce înțelege chestionarul de securitate al unui client când întreabă despre gestionarea schimbărilor.
Revizia pe care n-o programează nimeni
Rolurile și permisiunile se configurează o dată și apoi alunecă. Oamenii vin și pleacă, posturile se schimbă, acordările temporare devin permanente din uitare. Remediul e o revizie scurtă, de două ori pe an, care pune trei întrebări: cine are cont, mai are fiecare nevoie de rolurile pe care le deține și a plecat cineva? Pentru site-urile pe care le întreținem, această revizie face parte din calendarul de mentenanță, și de obicei îi ia persoanei de contact a clientului cincisprezece minute să confirme lista. Acel sfert de oră e una dintre cele mai bune investiții de securitate disponibile.
Proiectarea pentru organizația ta
Un model bun de permisiuni vine dintr-o conversație, nu dintr-un șablon. Începem întrebând cine lucrează pe site, ce face concret fiecare grup și ce ar fi o problemă dacă s-ar întâmpla din greșeală. De acolo propunem un set mic de roluri, le parcurgem cu oamenii care le vor deține și le rafinăm până când rolurile se potrivesc cu munca. Apoi implementăm, exportăm, testăm și lansăm, iar modelul devine parte din felul în care e întreținut site-ul, nu ceva configurat o singură dată.
Dacă răspunsul site-ului tău la „cine poate schimba asta?” e mai lung decât ar trebui, te putem ajuta să-l scurtezi. E un proiect mic cu efect de durată, iar oamenilor care îți editează site-ul le place de obicei o interfață care le arată doar ce le trebuie.