Mereu când am început o aplicație nouă pentru un client am avut acel feeling că parcă structura de management al utilizatorilor nu este cea finală, the chosen one, cea pe care să merg la sigur în toate proiectele. Cred că feelingul ăsta apare pe la toți programatorii care vor să își dezvolte permanent soluțiile, nu la cei care livrează ceva ca să fie bifată treaba.

De-a lungul timpului am creat 3-4 sisteme de autentificare, toate diferite și toate cu îmbunătățiri de la un client la altul. Am nevoie de o versionare foarte bine pusă la punct la nivel de funcționalități, documentație proprie și mod de utilizare a acestor funcții. Cumva, acest lucru este inevitabil și dacă soluțiile sunt personalizate de la un proiect la altul, nu poți să faci update-uri în urmă la toată lumea. E fizic imposibil. Numai la soluțiile SaaS putem veni cu update-uri și îmbunătățiri care să crească permanent valoarea adăugată clienților înrolați și care, cel mai probabil, plătesc un abonament recurent.

Revenind la proiectele on spot, custom made, rămâne întrebarea: „care este cea mai bună arhitectură pentru managementul utilizatorilor și a drepturilor de acces?”.

Pot spune că am testat toate tipurile de idei posibile și fiecare vine cu avantaje sau dezavantaje.

Să le luăm pe rând:

Clasica tabelă users

Că se numește „users”, „user”,”utilizatori”,”auth” sau oricum s-ar numi, cel mai adesea se creează o tabelă care conține numele utilziatorilor (în diverse formate), date despre aceștia și datele de autentificare (criptate sau nu într-un caz de programare neortodoxă).

Citește și: „Nu te încrede niciodată în parola ta„.

Dacă trebuie să stocăm date despre utilizatori, pur și simplu se vor crea coloane în plus în tabela utilizatorilor. Este varianta cea mai simplă care nu are nevoie de scripturi în plus sau de librării.

Pro:

  • rapiditate în implementarea modificărilor
  • rapiditate în dezvoltarea de sisteme CRUD pentru vizualizarea rapidă a informațiilor despre utilzatori
  • control mai bun asupra informațiilor stocate despre utilziatori
  • posibilitatea de a șterge mai rapid și mai ușor date despre utilizatori
  • rapiditate în crearea de sintaxe SQL fără subselecturi

Cons:

  • nu putem folosi decât relaționări one-to-one
  • nu putem avea sute de câmpuri despre utilizatori
  • nu putem avea variabile dinamice privind datele utilizatorilor
  • putem merge cu campuri foarte standard pentru drepturile de acces

Clasica tabelă users și tabelele relaționale

Spre deosebire de varainta precendentă, am scris în subtitlu „și tabelele relaționale” pentru drepturile de acces, în mod special.

O soluție pentru stocarea datelor one-to-many sau many-to-many este să folosim tabele de legătură sau indecși.

Pro:

  • relaționări multiple între utilziatori și functionalități și drepturile de acces la acestea
  • relaționări multiple cu orice tip de date se pot stoca despre activitatea utilizatorilor
  • putem gândi tabele speciale în funcție de conceptele logice cu care lucrăm (tabele pentru permisiuni, tabele pentru apartenența utilziatorilor la grupuri, tabele privind pachete de membership achiziționate, ș.a.m.d.)
  • informațiile sunt mai ușor de gestionat, fiecare fiind păstrată în cutia sa (practic, este ca și cum ne-am așeza niște cărți pe rafturi)
  • putem prelua foarte ușor componente reutilizabile de la un client la altul

Cons:

  • este nevoie de mai mult cod și de o mai bună cunoaștere a SQL pentru a crea funcții de editare, iar interfața grafică presupune mai mult efort pentru programare
  • pot apărea mai multe buguri și este nevoie de mai mult timp de testare
  • dezvoltatorul trebuie să cunoască foarte bine relațiile dintre tabele, să șe înțeleagă și să nu le uite!
  • este nevoie să se scrie sintaxe SQL sau modele (sisteme MVC) pentru fiecare tip de entitate în parte
  • pot apărea date orfane sau cu legături eronate între diversele entități
  • o structură incorectă sau reduntantă poate îngreuna aplicația sau poate crește numărul de execuții SQL per accesare de pagină (ex. problema WordPress care este foarte redundant)

Clasica tabelă users și stocarea datelor în format JSON sau serializat

Se practică din ce în ce mai mult stocarea datelor în format JSON sau serializat. Această abordare poate ajuta foarte mult în anumite situații, dar vine cu foarte multe inconveniente.

Pro:

  • putem lucra cu formate de date nescructurate, nedefinite, incerte
  • putem salva preferințe sau setări complexe despre o entitate fără să supraîncărcăm baza de date
  • mai ușor de transfera și prelucrat ca array client side sau server side

Cons:

  • extrem de greu de menținut din punct de vedere al programării
  • pot apărea erori de stocare și interpretare
  • nu se pot executa căutări corecte și rapide în baza de date (cu toate că ultimele versiuni de MySQL au suport pentur JSON)
  • pentru modificări în masă, trebuie creat un script care să itereze toate înregistrările și să corecteze toate evidențele ținând cont și de potențialele erori datorate nestandardizării
  • trebuie create librării speciale pentru standardizarea editării într-o interfață grafică dacă este nevoie

Clasica tabelă users și variabile în format vertical

O altă practică uzitată este aceea de a sotca variabilele într-o structură verticală, așa cum procedează arhicunoscutul WordPress. Acest lucru presupune că vom avea o tabelă pentru variabilele utilziatorilor ce conține, de regulă, 3 câmpuri (id utilizator, denumire variabilă, valoare variabilă).

Pro:

  • posibilitatea de a salva date cu un dinamism mare despre utilizatori în forme nestandardizate
  • reducerea semnificativă a numărului de tabele din baza de date

Cons:

  • este nevoie de mai mult cod și de o mai bună cunoaștere a SQL pentru a crea funcții de editare, iar interfața grafică presupune mai mult efort pentru programare
  • dezvoltatorul trebuie să cunoască foarte bine variabilele care există și cum sunt utilizate și unde
  • pot apărea valori orfane sau cu legături eronate între diversele entități
  • poate îngreuna aplicația sau poate crește numărul de execuții SQL per accesare de pagină

Despre managementul permisiunilor

Referitor la managementul permisiunilor, tipologia de acordare a drepturilor de acces poate diferi în funcție de arhitectura aplicației și a bazei de date.

De-a lungul timpului am identificat următoarele abordări privind entitățile la care se pot acorda permisiuni:

  1. Acordarea de permisiuni la nivel de rute ale aplicației
  2. Definirea unor permisiuni și alocarea acestora la utilziatori, grupuri și secțiuni din cadrul aplicației
  3. Definirea de permisiuni la nivel de clase
  4. Definirea de permisiuni variabilizate (acestea sunt definite ca niște variabile ușor de înțeles, iar validarea acestora se face prin condiții redundante în întreaga aplicație)
  5. Definirea de permisiuni CRUD (create, read, update, delete)
  6. Definirea de permisiuni matriceale
  7. Definirea de permisiuni cu granularitate infinită și complexitate maximă (am creat un astfel de sistem și pot spune că mă ajută pentru că pot îndeplini cerințele oricărui tip de client, dar mă doare capul când trebuie să definesc noi permisiuni)
  8. Definirea de permisiuni bazat pe tipul de cont
  9. Definirea de permisiuni bazat pe variabile (ex. apartenență la un grup sau membership plătit)
  10. Definirea de permisiuni bazat pe niveluri
  11. Definirea de permisiuni moștenite
  12. Permisiuni bazate pe apartenența datelor
  13. Permisiuni la nivel de date la care există acces (mai precis, câmpuri din baza de date)
  14. Permisiuni bazate pe capabilități standard (similar cu cea pe niveluri sau cea pe grupuri sau cu cea variabilizată)
  15. Permisiuni bazate prin excludere

Conectează-te ca abonat și vei primi o notificare atunci când dau drumul articolului despre managementul permisiunilor în aplicațiile web custom.

Proiecte de suflet

ASE Student Run

Eveniment non-profit pentru studenti si elevi

Crosul Iubirii

Pentru toti alergatorii care iubesc

Afterwork Athletics

Competitie Corporate în sala de atletism

Revigorarea atletismului bucureștean

Din funcția de președinte al Asociației Municipale de Atletism Bucuerști

Bucharest YMI

Young Marketers Internship

About the author

Coman Paul-Tiberius

Sunt un adevărat iubitor al sportului, un voluntar convins și un spirit plin de inițiativă. La bază sunt specialist în marketing și management, iar ca profesionalizare, programator web.
Inițiativa este sportul meu favorit. Prin urmare, este nevoie de un astfel de site care să-mi prezinte proiectele.
Mereu deschis parteneriatelor și colaborărilor, Paul.
PS:Mă puteți contacta mereu prin formularul de contact.

Leave a Comment