Temat: Koncepcja ACL-i
Jeśli chcesz jakąś "inną" koncepcję ACL'i to polecam oglądnięcie Pyramid. Tam idea wygląda następująco:
Request poza routingiem ma przypisaną ścieżkę do resource. Czyli np. poza tym że jest to '/cośtam/gdzieśtam/{id}' (routing) jest to też '/posts/{id}' (resource). Root resource jest znany. Potem zaczyna się szukanie "/" (root) -> "/posts" (root['posts']) -> "/posts/{id}" (root['posts'][123] na przykład). ACL jest sprawdzany w każdym resource - czyli "root" może np. mieć DENY-*-*, ALLOW-view-g:registered, ALLOW-*-g:admins. Potem "root['posts']" może mieć ALLOW-edit-g:editors. Sam post ma ALLOW-*-u:twórca Itd...
Oczywiście przy każdym stopniu ten resource może być generowany na żywo zależnie od elementu. Czyli jakiś szczególny post może mieć swojego przypisanego ACLa (u:twórca będzie konkretnym userem z bazy). Skąd te dane pochodzą i jak je generować zależy tylko od implementującego.
Teraz w strefie routingu każda ścieżka dostaje jeszcze parametr co jest wymagane, np. "view" w przykładzie wyżej.
Za pierwszym razem - wygląda bardzo zamieszanie. Później jest już super. Pyramid używa tych resource'ów trochę bardziej ponieważ są też przekazywane do kontrolera i można używać tych danych uzyskanych wcześniej... ale to już inna bajka.
Stanisław P. edytował(a) ten post dnia 01.05.11 o godzinie 22:35