![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 285 Pomógł: 37 Dołączył: 18.12.2007 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
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. |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 285 Pomógł: 37 Dołączył: 18.12.2007 Skąd: Łódź Ostrzeżenie: (0%) ![]() ![]() |
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 (IMG:style_emoticons/default/wink.gif) 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. Ten post edytował netmare 19.12.2012, 10:28:33 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 17.10.2025 - 18:18 |