Witam,

Po długiej przerwie w php muszę usiąść i zrobić w symfony2 drobny interfejs WWW do aplikacji desktopowej. Aplikacja posiada użytkowników, którzy w rozumieniu interfejsu WWW są administratorami i ich loginy przechowywane są w schemacie aplikacji. Aplikacja operuje na pewnych danych powiązanych z ludźmi, którzy w rozumieniu interfejsu WWW są użytkownikami i mogą sobie pewne infoprmacje sprawdzić, natomiast do aplikacji nie mają dostępu, ich loginy i hasła muszą być przechowywane w schemacie interfejsu WWW.

Rola administratora sprowadza się do tworzenia użytkowników i nadawania im uprawnień do części użytkowej (to jakie upraweninia danemu użytkownikowi może nadać administrator określane jest w aplikacj w dość skomplikowany sposób i interfejs WWW musi odtworzyć algorytm i odpowiadać dynamicznie).

Użytkownik może mieć dostęp do około 20 pozycji, które mają być konfigurowane przez Administratora.

Oczywiście w necie jest mnóstwo tutriali o uprawnieniach i ACL, ale ze względu na stopień skomplikowania nie potrafię wyciągnąć wiedzy jak się za to w ogóle zabrać.

Moje pytanie na ile mogę wykorzystać jakieś gotowe rozwiązania (JMS, FOS, Sonata), a na ile muszę zrobić to sam?
Czy powienienem dla każdego uprawenienia definiować nową rolę dziedziącą po ROLE_USER?
Na ile komplikuje sprawę chęć użycia wspólnej formatki logowania (np. wpływ na encje)?

Proszę o pomoc, bo projekt ma skończony termin realizacji, a jak źle zacznę z uprawnieniami to pewnie położę ten termin.

Dołączam się do posta.

Symfony ma całkiem dobrze zaprojektowany mechanizm autoryzacji, który bardzo łatwo rozbudować o nowe, niekonwencjonalne metody sprawdzania uprawnień.
To jest kluczową sprawą, a niestety w ogóle nie opisałeś jej. W jaki sposób/na podstawie jakich danych/na jakich warunkach określana jest decyzja o tym czy udzielić dostępu do danego zasobu? Dodatkowo z jakimi rodzajami zasobów mamy tutaj do czynienia?

Od odpowiedzi na powyższe pytanie zależeć będzie z jakich mechanizmów autoryzacji skorzystasz, czy będą to predefiniowane role, ACL czy może zupełnie co innego.

Kompletnie niezrozumiałe.

Postaram się doprecyzować.

Otóż administrator operuje na użytkownikach którzy mogą być zapisani w różnych jednostkach organizacyjnych. Każda taka jednostka organizacyjna przechowywana jest w osobnej tabeli. W jednostce organizacyjnej realne wartości to 2000 uzytkowników. Interfejs WWW w swoich strukturach przechowuje mapowanie login -> id jednostki organizacyjnej. Uprawenienia w aplikacji desktopowej realizowane są dynamicznie przez sprawdzenie czy administrator może w ogóle coś podejrzeć w jednostce organizacyjnej jeśli tak to na poziomie użytkownika zdefiniowane są poziomy zdefiniowanych uprawnień wyrażone intami dla pewnych grup merytorycznych. Abstrakcyjny przykład jednostki organizacyjne Fabryka 1, Fabryka 2; grupy merytoryczne przy użytkowniku: frekwencja, kontrakty. Teraz na podstawie iluś tabel w bazie jest analizowane czy Administrator 1 może włączyć uzytkownikowi iksińskiemu podgląd kontraktów.

Od strony założeń nie może być warstw pośrednich dane mają być zawsze aktualne. A budowanie całej listy użytkowników ze wszystkich fabryk przy każdym odświeżeniu strony administratora nie ma sensu ze względu na skalę więc to co może dany administrator zmienić musi być ustalane dynamicznie.

Wpływ na encje wydaje mi się nieistotny - potrzebuję chyba użyc po prostu dwóch UserProviderów, przynajmniej do takich wniosków doszedłem wertując dokumentację symfony2 i chciałbym się w tym upewnić.

W miarę możliwości chciałbym żeby uprawnienia były realizowane jakoś dynamicznie. Rozsądnym wydaje mi się podzielenie na bundle. 1 bundle główny i reszta bundli z których każdy odowiada za jakąś pozycję w menu. Kontroler takiego bundla implementuje jakiś iMyBundle. Przy edycji uprawnień zczytuje się lista bundli chyba kernel.bundles jakoś to zapewni i sprawdzam czy dany bundle implementuje ww. interfejs. Jeśli tak to zczytuje jakąś statyczną metodą rolę, opis w menu i wymaganą grupę merytoryczną admina.

Czy coś takiego trzyma się kupy? (Z założenia ja piszę taki portal, ale włączanie dodatkowych, później dodanych funkcjonalności u klienta to zajęcie osoby nie mającej pojęcia o php, dlatego chcaiłbym to mocno zautomatyzować)
Jeśli tak to jak podejść do funkcjonalności która mogłaby mieć listę uprawnień (np uzytkownik może zrobić show, ale nie może edit).

Ostatni problem związany z uprawnieniami, choć nie wiem czy to na ten wątek: zdefiniowane są grupy adresowe uważane za adresy wewnętrzne admin może się logować tylko z nich a user ma jakiś bool czy tylko z wew czy z dowolnego. Jak to w ogóle rozwiązać w co się wpinać przy logowaniu żeby sprawdzić i ewenetualnie zabronić logowania w zależności od loginu?

Ani trochę, ale z tych wyrywkowych informacji wydaje się, że standardowe role + ACL w pełni wystarczą.
Możesz to z powodzeniem zrealizować w UserProviderze.

Możesz doprecyzować jak to połączyć z ACL?

To co może robić admin zarządzane jest przez desktop, nie wiem jak to spiąć...

Napisz jeszcze raz jaki jest docelowy sposób działania (od strony użytkownika każdego typu) całego systemu. Innymi słowy, co chciałbyś móc zrobić, a nie jak masz już to (częściowo) zrobione. Tylko na spokojnie i bez przeskakiwania z tematu na temat.

Jest pewna duża komercyjna aplikacja desktopowa. Część klientów zgłaszała zapotrzebowanie na stworzenie interfesju WWW pozwalającego swoim pracownikom wyciągnąć z dużej bazy danych pewne informacje ich dotyczące, żeby nie zawracali głowy osobom pracującym na aplikacji (w dużej firmie najwyżej jest to kilkadziesiąt osób ). Jeżeli pracownik zgłosi się do tych osób ma dostać login i hasło do interfejsu WWW i tam sobie sprawdzać rzeczy których potrzebuje. W każdej firmie jest grupa jakiś pracowników wysokiego szczebla np. Dyrektorzy i nie każdy z użytkowników aplikacji ma dostęp do takiej osoby. Więc w ramach interejsu WWW musi to zostać odtworzone, żeby użytkownik aplikacji nie mógł uzyskać dostępu do danych dla niego zastrzeżonych, poprzez utworzenie nowego loginu. Jak pisałem wcześniej od strony użytkowej możemy podzielić na pewne logiczne obszary i użytkownik może mieć dostęp do jednego obszaru u danej osoby do drugiego nie. W skrócie mozna powiedzieć że pracownik ma przypisane wymagania obszar_1=200, obszar2=1, a użytkownik ma określony poziom uprawnień 100, więc użytkownik może u niego podejrzeć obszar_2, a do obszar_1 nie ma dostępu. Ponieważ aplikacja składa się z X modułów i występuje u klienta w różnej konfiugracji, z czasem okaże się że interfejs WWW musi składać się z modułów pozwalających wyciągać inne dane i występować u klienta w różnej konfiguracji. Instlacja dodatkowego modułu musi być prosta, ponieważ nie zajmuje się tym programista PHP tylko wdrożeniowiec. Jednym z głównych założeń jest że aplikacja nie będzie dostosowywana do interfejsu WWW. W bazie danych chcę utworzyć dodatkowy schemat i będzie to jedyne miejsce gdzie użytkownik bazy z którego korzysta interfejs ma prawa zapisu. W związku z tym że aplikacja nie będzie dostosowywana (poza przypisaniem użytkownikowi innego hasła do WWW) muszę przeniesć zarządzanie częścią WWW na samo WWW. Stąd podział na role Administrator - czyli użytkownik aplikacji mogący się zalogować do interfejsu i nadający uprawnienia użytkownikom i Użytkownik - czyli osoba mogąca zalogować się do interfejsu i mogąca sprawdzić pewene informacje z nią związane. Użytkownik musi posiadać uprawnienia do modułów, bo napewno zdarzą się sytuacje kiedy użytkownik zdecyduje, że nie życzy sobie aby dana informacja była osiągalna z poziomu przeglądarki w obawie przed atakiem.
I ostatnia sprawa to opisane już uprawnienie do logowania z zewnątrz, ale tą część uważam za zamkniętą po Twoim wyjaśnieniu i tylko ubolewam że rozwiązanie było takie proste

Teraz jeszcze to co się kupy nie trzymało ani trochę. Pomyślałem że takie rozwiązanie pozwoli na bezobsługową instalację nowej funkcjonalności (wcześniej pisanej jako moduł). I automatycznie spowoduje poszerzenie listy zarządzalnych uprawnień użytkownika.