Implementering av ACL-begrensninger, mer enn å tillate / nekte

Jeg har utviklet et lite, men effektivt MVC-stil rammeverk for bruk i et program, og jeg implementerer en ACL-kontroll per forespørsel.

Raske detaljer: PHP 5.3+; MySQL 5.1+ ; Tilpasset rammeverk, "MVC-lignende"

Fra nå av er ACL-sjekken enkel " nekte-hvis-ikke-hvitlisting "; Hver -gruppe kan tildeles tillatelse til visse forespørsler. For eksempel:

privilege                       permission
+----------+---------------+    +---------------+---------------+
| group_id | permission_id |    | permission_id | handler_key   |
+----------+---------------+    +---------------+---------------+
|     1    |       1       |    |       1       | lorem_ipsum   |
|     1    |       2       |    |       2       | hello_world   |
|     2    |       3       |    |       3       | foobar        |
+----------+---------------+    +---------------+---------------+

( bruker og gruppe ekskludert for kortfattethet, men modellene deres er ikke noe uvanlig )

Uansett, rammeverket mitt ruter URI til den aktuelle handler_key via en handler / path tabl e ( for å koble fra filsystemarkitekturen ) Forespørselen blir deretter sendt til behandleren, gitt group_id assosiert med forespørselen, er hvitlistet for den handler_key .

Jeg er nysgjerrig på, hva er den beste tilnærmingen til å implementere lagring / kontroll av vilkårlige ( brukerdefinerte ) begrensninger? Eksempler på tilfeller vil være:

  • Tillat bare den gitte gruppen å påberope seg en handler hverdager, mellom 8:00 og 17:00.
  • Tillat bare den gitte gruppen å påkalle en handler for å endre "eide" data; dvs. data opprettet av den tilknyttede brukeren . Denne sjekken vil kanskje omfatte en sjekk av user_id -feltet som er knyttet til innholdet som skal endres av behandleren, og user_id tilknyttet forespørselen

jeg hadde en flagg kolonne, men det er ikke fremtidssikret med innføring av flere krav til funksjoner, grupper og begrensninger. Jeg tenkte i følgende retning, men hva skulle jeg bruke?

permission
+---------------+----------------------------+
| permission_id | handler_key   | constraint |
+---------------+---------------+------------+
|       1       | lorem_ipsum   |     ?      |
|       2       | hello_world   |     ?      |
|       3       | foobar        |     ?      |
+---------------+---------------+------------+

Unødvendig avklaring:

( Merk: kode ble skrevet her, ikke copypasta fra prosjekt )

For å avklare noe av sjargonget her; håndterere (spesielt webhåndterere) er egentlig kontrollere , for de som er kjent med MVC-arketypen.

Deres spesifikke implementering er en enkelt PHP-fil, som returnerer en funksjon som skal kalles av avsenderen, eller den som ringer underhåndteringen. For eksempel:

<?php
    $meta = array('subhandlers' => array());
    return function($request, $response) use($meta){
        $response['foo'] = 'bar';
    };

Mitt rammeverk bruker webhåndterere og API-håndterere ; webhåndterere mater data inn i et responsobjekt (i utgangspunktet en samling hierarkiske visninger ) som genererer HTML. Dataene er innhentet ved å påkalle API-håndtererne, som ganske enkelt returnerer rådata (API-håndtere kan betraktes som representasjoner av -modellen , og går tilbake til typisk MVC)

Sammensatte håndterere er i hovedsak et abstraksjonslag, ettersom de er håndtere selv som påkaller håndterere for å samle data. Min nåværende implementering av ACL-sjekken, gjør en kortvarig sjekk av alle nestede håndtere (via $ meta , en arrayvariabel erklært å fungere som metadataoverskrift for behandleren) For eksempel:

<?php
    $meta = array('subhandlers' => array('my_subhandler'));
    return function($request, $response) use($meta){
        $someData = Caller::call('my_subhandler', array($request, $response));
        $response->bind($someData);
    };
8
задан Dan Lugg 26 May 2011 в 06:47
поделиться