Answer-ID
Mai mult

Care este cel mai bun mod de a trata mai multe tipuri de permisiuni?

Deseori întâlnesc următorul scenariu în care trebuie să ofer diferite tipuri de permisiuni. În primul rând folosesc ASP.NET / VB.NET cu SQL Server 2000.

Scenariu

Vreau să ofer un sistem de permisiune dinamic care să poată funcționa pe diferiți parametri. Să spunem că vreau să dau fie unui departament, fie doar unei anumite persoane, acces la o aplicație. Și pretindeți că avem o serie de aplicații care continuă să crească.

În trecut, am ales una dintre următoarele două căi pe care știu să le fac.

1) Utilizați un singur tabel de permisiune cu coloane speciale care sunt utilizate pentru determinarea modului de aplicare a parametrilor. Coloanele speciale din acest exemplu sunt TypeID și TypeAuxID. SQL ar arăta așa.

SELECT COUNT(PermissionID)
FROM application_permissions
WHERE
(TypeID = 1 AND TypeAuxID = @UserID) OR
(TypeID = 2 AND TypeAuxID = @DepartmentID)
AND ApplicationID = 1

2) Utilizați o tabelă de mapare pentru fiecare tip de permisiune, apoi alăturați-le pe toate împreună.

SELECT COUNT(perm.PermissionID)
FROM application_permissions perm
LEFT JOIN application_UserPermissions emp
ON perm.ApplicationID = emp.ApplicationID
LEFT JOIN application_DepartmentPermissions dept
ON perm.ApplicationID = dept.ApplicationID
WHERE [email protected]
  AND ([email protected] OR [email protected] OR
 (emp.UserID IS NULL AND dept.DeptID IS NULL)) AND ApplicationID = 1
ORDER BY q.QID ASC

Gândurile mele

Sper că exemplele au sens. L-am pietruit împreună.

Primul exemplu necesită mai puțină muncă, dar nici unul dintre ei nu se simte cel mai bun răspuns. Există o modalitate mai bună de a face față acestei situații?

Programare
sql
permissions
Comentarii la întrebare (0)

Modul în care de obicei folosesc sistemele de permisiuni de codare are 6 tabele.

  • Utilizatori - aceasta este destul de dreaptă, este tabela tipică a utilizatorilor dvs.
  • Grupuri - ar fi sinonim cu departamentele dvs.
  • Roluri - acesta este un tabel cu toate permisiunile, inclusiv, de asemenea, un nume lizibil și o descriere
  • Users_have_Groups - acesta este un tabel mult-la-multe despre ce grupuri aparține unui utilizator
  • Users_have_Roles - un alt tabel mult-la-multe despre ce roluri sunt atribuite unui utilizator individual
  • Groups_have_Roles - tabelul final multi-la-multe despre ce roluri fiecare grup are

La începutul unei sesiuni de utilizatori veți executa o logică care va scoate fiecare rol pe care l-au atribuit, fie prin intermediul unui director, fie printr-un grup. Apoi codați aceste roluri ca permisiuni de securitate.

Așa cum am spus că asta fac în mod obișnuit, dar șarpele tău poate varia.

O abordare pe care am folosit-o în diferite aplicații este aceea de a avea o clasă generică PermissionToken care are o proprietate Valoare variabilă. Apoi, interogați aplicația solicitată, vă indică ce PermissionTokens sunt necesare pentru ao utiliza.

De exemplu, aplicația de expediere vă poate spune că are nevoie de:

new PermissionToken()
{
    Target = PermissionTokenTarget.Application,
    Action = PermissionTokenAction.View,
    Value = "ShippingApp"
};

Acest lucru se poate extinde, evident, la Creare, Editare, Ștergere etc și, datorită proprietății personalizate Valoare, orice aplicație, modul sau widget poate defini permisiunile proprii. YMMV, dar aceasta a fost întotdeauna o metodă eficientă pentru mine, pe care am descoperit-o la scară bine.

Sunt de acord cu John Downey.

Personal, uneori, folosesc o enumerare marcată cu permisiuni. În acest fel, puteți utiliza operațiile bitului AND, OR, NOT și XOR pe elementele enumerării.

"[Flags]
public enum Permission
{
    VIEWUSERS = 1, // 2^0 // 0000 0001
    EDITUSERS = 2, // 2^1 // 0000 0010
    VIEWPRODUCTS = 4, // 2^2 // 0000 0100
    EDITPRODUCTS = 8, // 2^3 // 0000 1000
    VIEWCLIENTS = 16, // 2^4 // 0001 0000
    EDITCLIENTS = 32, // 2^5 // 0010 0000
    DELETECLIENTS = 64, // 2^6 // 0100 0000
}"

Then, you can combine several permissions using the AND bitwise operator.

For example, if a user can view & edit users, the binary result of the operation is 0000 0011 which converted to decimal is 3.
You can then store the permission of one user into a single column of your DataBase (in our case it would be 3).

Inside your application, you just need another bitwise operation (OR) to verify if a user has a particular permission or not.

În plus față de soluțiile lui John Downey și a lui perecuyper, am adăugat un bit "Explicit Deny" la sfârșitul / începutul câmpului de biți, astfel încât să puteți efectua permisiuni adiționale după grup, membru de rol și apoi să scăpați permisiunile bazate pe denunțarea explicită intrări, la fel ca NTFS funcționează, pe bază de permisiune.

Sincer, funcțiile ASP.NET de membru / roluri ar funcționa perfect pentru scenariul descris de dvs. Scrierea propriilor tabele / procs / clase este un exercițiu excelent și puteți obține un control foarte frumos asupra detaliilor minuscule, dar după ce le-am făcut eu însumi, am concluzionat că este mai bine să folosiți doar materialele construite în .NET. O mulțime de cod existent este conceput pentru a lucra în jurul valorii de care este frumos la bine. Scrierea de la zero mi-a luat aproximativ 2 săptămâni și nu a fost acolo în cazul în care aproape la fel de robust ca NET. Trebuie să codificați atât de multă prostie (recuperarea parolei, blocarea automată, criptarea, rolurile, interfața de permisiune, tone de procs etc.), iar timpul ar putea fi mai bine petrecut în altă parte.

Ne pare rău dacă nu am răspuns la întrebarea dvs., sunt ca tipul care spune să învețe c # când cineva întreabă o întrebare VB.