Methodieken voor snelle permissie controle

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb een model waarbij objecten beveiligd worden met permissies. Deze permissies zijn variabel en kunnen in principe onbeperkt zijn. Ik heb dan even in grote lijnen ook een tabel met permissies, een tabel met objecten, en een tabel waarbij een permissie en een object een relatie krijgen.

Ik ben een treeview aan het vullen met deze objecten. Als er op een object geen permissies zijn gezet worden deze over geerfd van het eerste object in de bloodline die wel permissies heeft.

Nu wil ik per object een lijst met permissies hebben, zodat ik in de interface bijvoorbeeld het "edit" knopje kan uitschakelen als ik een node in de treeview selecteer waarop ik geen "edit" permissies heb.

Dit betekend dat ik dus voor elk object een functie uitvoer die permissies ophaalt, en dit recursief naar zijn parent uitvoerd (ivm overerven rechten) totdat er permissies zijn gevonden. Om het geheel nog eventjes erger te maken, op een object kan ik groepen, rollen, en users hangen. Elk van deze drie bestaat uit een configuratie van permissies. Een rol override de rechten van een groep, en een user override de rechten van een rol.

Als er op een object dus een groep hangt met het recht "edit", maar ik als user ben ook gedefinieerd op het object maar zonder het recht "edit" dan betekend dit uiteindelijk dat ik geen "edit" rechten heb.

Om een lang verhaal kort te houden, de performance hit voor deze lookup is veel te zwaar per object. Het begint bij 40ms en het eindigt bij 180ms per lookup omdat de server echt moet beuken. Er moeten namelijk per object permissies worden opgehaald, en overrides worden bepaald.

Waar ik naar aan het kijken ben is een methode om een soort lookup table te creeeren voor razendsnel bepalen van permissies. Dat zou betekenen echter dat ik voor elk object alle mogelijke mogelijkheden moet opslaan, dat moet efficienter kunnen.

code:
1
2
3
4
5
6
objectid  groupid    rollid   userid    permissionlist
1            1            null     null       add,edit,remove
1            2            null     null       add
1            3            null     null       edit,remove
1            null         1        null       edit,remove,publish
1            null         null     1          remove


Dit is op zich snel, maar ontzettend gevoelig, maar ik was benieuwd of er mensen voor zelfde problemen hebben gestaan.

Als je maar een enkel object bewerkt en op rechten checked is het een non-issue. Maar als je bijvoorbeeld 100x een object ophaalt voor de treeview dan wordt het een ramp.

Ik heb hier een gedeelte van het diagram staan, waarbij ik de permissie gedeeltes rood heb gemaakt:
http://www.mschopman.demon.nl/diagram.gif

[ Voor 8% gewijzigd door Verwijderd op 20-01-2005 21:06 ]


Acties:
  • 0 Henk 'm!

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Verwijderd schreef op donderdag 20 januari 2005 @ 21:02:
Ik ben een treeview aan het vullen met deze objecten. Als er op een object geen permissies zijn gezet worden deze over geerfd van het eerste object in de bloodline die wel permissies heeft.
Klinkt als een Chain Of Responsibility;)
Om een lang verhaal kort te houden, de performance hit voor deze lookup is veel te zwaar per object. Het begint bij 40ms en het eindigt bij 180ms per lookup omdat de server echt moet beuken.
Kun je het niet gewoon volledig in het geheugen houden? En dan zorgen dat je de objecten na het bewerken wegknikkerd. Zodat je later weer verse hebt, met eventueel nieuwe rechten.

En het zou misschien ook een idee zijn om het lazy te maken. Dus niet alles in 1 keer ophalen. Ik weet trouwens ook niet hoeveel je van die boom in 1 keer wilt laten zien, maar als je werkt met open klappende bomen, dan zou je daar misschien ook nog iets kunnen doen met lazy ophalen rechten.

[ Voor 10% gewijzigd door Alarmnummer op 20-01-2005 21:25 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Alarmnummer schreef op donderdag 20 januari 2005 @ 21:22:
Kun je het niet gewoon volledig in het geheugen houden? En dan zorgen dat je de objecten na het bewerken wegknikkerd. Zodat je later weer verse hebt, met eventueel nieuwe rechten.

En het zou misschien ook een idee zijn om het lazy te maken. Dus niet alles in 1 keer ophalen. Ik weet trouwens ook niet hoeveel je van die boom in 1 keer wilt laten zien, maar als je werkt met open klappende bomen, dan zou je daar misschien ook nog iets kunnen doen met lazy ophalen rechten.
Het gaat nu alleen al puur om het weergeven van een niveau van de treeview in een xml format (welke vervolgens wordt geparsed naar een javascript treeview).

[haal data op]
[for each in data]
[haal permissies op]
[output xml]
[nog een keer]

Voor het editten van een object doe ik puur isAuthorized(objectid,userid,"edit")

Het is juist de complete logica van het overriden, ophalen van data, vergelijken, etc. die het voor een grote collectie objecten zo traag maakt.

Acties:
  • 0 Henk 'm!

  • Genoil
  • Registratie: Maart 2000
  • Laatst online: 12-11-2023
kun je misschien snelheidswinst boeken door een onderscheid te maken tussen de voor het displayen van een TreeNode in een TreeView noodzakelijke permissies, die mijns inziens niet meer zijn dan "read", "write" en "delete" en de permissies die pas van belang worden bij het displayen/bewerken van de gegevens die aan de TreeNode hangen? of is dat zo'n beetje alles wat er is?

anders kun je misschien winst boeken door die permissionlist uit te drukken in een getal waardoor de check sneller is, of is dat voorbeeld maar een soort van pseudocode?

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Nee, ik heb momenteel 15 permissies, het is ook uitgebreide security op meerdere niveaus. Wat ik eens ga proberen is het aanleggen van een tijdelijke cache, waar ik objecten in vastleg.

Bijvoorbeeld

niveau 1 (wel permissies)
- niveau 2 (geen permissies)
- niveau 2 (geen permissies)
- niveau 2 (geen permissies)
- niveau 2 (geen permissies)
- niveau 2 (wel permissies)

Dan wordt dus een cache aangelegd voor niveau 1. Bij het laden van niveau 2 kan dan de cache worden gebruikt voor elke iteratie en voorkom je recursie voor een lookup op de parent. Immers is die al een keer aan bod geweest.

Je ontkomt echter niet aan individuele controles op alle niveau 2 entries. Die cache is puur bedoeld om recursie aan te pakken en te minimaliseren door hergebruik van informatie.

Recursie was ook de grootste hit zag ik. In principe is het ook een gevolg van het per object telkens ophalen van permissies, controleren en dit vaak achter elkaar.

[ Voor 10% gewijzigd door Verwijderd op 20-01-2005 22:16 ]


Acties:
  • 0 Henk 'm!

  • riezebosch
  • Registratie: Oktober 2001
  • Laatst online: 18-09 10:39
Als ik je verhaal zo even vluchtig doorlees: waarom achterhaal je recursief de permissies van de parent? Een object heeft meestal toch maar 1 parent (die ook weer maximaal 1 parent heeft), en kan je dus toch ook prima iteratief doen? Kan misschien al schelen in je performance.

Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
riezebosch schreef op donderdag 20 januari 2005 @ 23:40:
Als ik je verhaal zo even vluchtig doorlees: waarom achterhaal je recursief de permissies van de parent? Een object heeft meestal toch maar 1 parent (die ook weer maximaal 1 parent heeft), en kan je dus toch ook prima iteratief doen? Kan misschien al schelen in je performance.
Nee in mijn geval niet. Ik heb bijvoorbeeld een bibliotheek met artikelen. Elk artikel hangt hier in folders (categorien). Binnen de bibliotheek zou een artikel zijn permissies overerven van de folder, tenzij de artikel zelf permissies heeft.

Zodra ik echter een artikel wil gaan gebruiken, ga ik een relatie plaatsen tussen pagina en artikel. Dit maakt het voor mij mogelijk om een artikel op meerdere pagina's te hergebruiken. Ik gebruik gewoon many to many relationships. Maar..... zodra je het artikel gaat hangen aan een pagina moet het artikel zich houden aan de rechten van de pagina. Kortom, op dat moment erft het artikel permissies over van de pagina, tenzij het artikel zelf permissies heeft gekregen.

Dit kan dus betekenen dat onder pagina a je bepaalde bewerkingen wel mag uitvoeren en onder pagina b niet. Het klinkt wat abstract maar de interface maakt het allemaal erg intuitief. Kortom, mijn objecten kunnen een theoretisch oneindig aantal parents hebben.

[ Voor 4% gewijzigd door Verwijderd op 20-01-2005 23:49 ]


Acties:
  • 0 Henk 'm!

  • Nvidiot
  • Registratie: Mei 2003
  • Laatst online: 03-06 16:38

Nvidiot

notepad!

Een tabel zal vrij veel lege entries hebben neem ik aan? Dan zou je eens kunnen kijken naar "Row Displacement" of "Graph Coloring" om de tabellen klein te houden maar wel snelle access te krijgen. (Waar een boek over vertalerbouw al niet nuttig voor is: Modern Compiler Design) :)

What a caterpillar calls the end, the rest of the world calls a butterfly. (Lao-Tze)


Acties:
  • 0 Henk 'm!

  • justmental
  • Registratie: April 2000
  • Niet online

justmental

my heart, the beat

Ik heb een applicatie met een vergelijkbaar model voor permissies. Daar werk ik nu met 1 query om de rechten per object op te halen, dat is dan wel een 'connect by' query welke volgens mij specifiek voor oracle is.
Bij het ontwerp had ik bedacht dat als dit performance problemen op zou leveren ik over zou kunnen stappen op een afgeleide tabel met de uitgewerkte rechten. Deze wordt dan wel heel groot, maar de lookups zijn dan altijd op index en de mutaties zijn gering.
Daarnaast zou je met bulk lookups kunnen werken als er veel objecten zijn om de permissies van te controleren.

Who is John Galt?


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Nvidiot schreef op vrijdag 21 januari 2005 @ 00:02:
Een tabel zal vrij veel lege entries hebben neem ik aan? Dan zou je eens kunnen kijken naar "Row Displacement" of "Graph Coloring" om de tabellen klein te houden maar wel snelle access te krijgen. (Waar een boek over vertalerbouw al niet nuttig voor is: Modern Compiler Design) :)
Als het goed is geen enkele lege entry.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik heb ook zoiets overwogen maar dat betekend in mijn geval dat ik voor alle groepen, alle rollen, alle users alle objectrelaties moet nagaan op permissies. Op zich zou je dat dan elke keer moeten doen bij het plaatsen van permissies op een object (direct zetten, of indirect door toekenning aan een parent).

Op zich hoef je maar een enkele keer deze lookup aan te maken, en dat is op een systeem met reeds objecten in zich. Daarna kan je het per object bekijken. De tabel in mijn topicstart was volgens mij wat jij bedoelde.

[ Voor 22% gewijzigd door Verwijderd op 21-01-2005 00:10 ]

Pagina: 1