System Eliminacji Studentów, który Jest był już Aktywny [dla tych, co się nie wyspali: SESJA] oraz tygodniowy wyjazd na narty skutecznie uniemożliwił mi wyprodukowanie czegokolwiek na blogu, za co przepraszam wszystkich najmocniej i obiecuję poprawę. Ze względu na to, że aktualnie jestem na etapie powrotu do „normalności” [czytaj: nie miałem komputera od ponad tygodnia] dzisiaj chciałbym poruszyć nieco lżejszy i „bardziej abstrakcyjny” [czytaj: nie będzie kodu] temat. Liczę na Waszą aktywność w komentarzach, ponieważ „wyjątkowo” cały wpis zamiast przedstawiać mój punkt widzenia będzie tylko lekko sugerował pewne możliwości. Tym razem jest on ukierunkowany na zapoznanie się z Waszą opinią. Mam nadzieję, że dzięki swoistej „burzy mózgów” dojdziemy do ciekawych wniosków. Zapraszam do lektury.
Wstęp.
W czym problem? Otóż: chciałbym rozważyć różne sposoby tworzenia / integracji paneli administracyjnych w stronach / aplikacjach internetowych. Ze swojej strony opisuję dwie opcje, jakie nasunęły mi się po krótkim przemyśleniu całej sprawy, ale mam nadzieję, że razem damy radę wymyślić więcej. ;] Zyskiem z rozwiązania tej „niejasności” będzie „jedynie” świadomość dobrze ugruntowanego i przemyślanego rozwiązania, jednak wydaje mi się, że jest ona warta uwagi.
Wariant I: Oddzielna aplikacja.
Pierwszym wariantem tworzenia panelu administracyjnego jest oczywiście oddzielny skrypt. Każdy, kto po raz pierwszy zetknął się z samym problemem stworzenia „zarządzalnej” strony internetowej prawdopodobnie wpadł na pomysł zrobienia oddzielnej aplikacji, która oferowałaby możliwość interakcji z tymi samymi danymi, co strona zarządzana. Jest to rozwiązanie stosunkowo proste, które stosowałem do tej pory bez większego zastanowienia nad sensem / celem / optymalnością i – co ważne – sprawdzało się znakomicie. Szczególnie na tle ostatnich wpisów dotyczących frameworka symfony, który posiada bardzo fajne narzędzie „Admin Generator” podejście to wydaje się najmniej pracochłonne i najbardziej optymalne z punktu widzenia ewentualnej rozbudowy serwisu – wszelkie operacje na panelu nie mają wpływu na działanie samej strony. Ważne jest też to, że raz napisany panel administracyjny możemy wykorzystać w innym projekcie, co dodatkowo oszczędza pracy naszym palcom [głowie też, ale w mniejszym stopniu, bo połączenia między odpowiednimi neuronami już powstały ;]]. Wypunktujmy zatem [, dla tych, co nie lubią czytać ;]]:
- Możliwość automatycznego wygenerowania panelu przez narzędzia takie jak Admin Generator frameworka symfony.
- Łatwość rozbudowy.
- Niezależność od strony zarządzanej.
- Możliwość przeniesienia gotowego produktu do innego projektu.
Wariant II: Zintegrowany z aplikacją.
Innym sposobem na rozwiązanie problemu „zarządzalności” może być integracja funkcjonalności panelu w stronie zarządzanej. Możemy to zrobić na wiele sposobów, najbardziej optymalny [moim zdaniem] wydaje się ten polegający na wyświetleniu dodatkowych opcji zalogowanym użytkownikom o odpowiednim poziomie uprawnień. W ten sposób użytkowanie strony, szczególnie, jeśli dostęp do elementów „zaawansowanych” mają osoby spoza głównej grupy twórców [np. moderatorzy i inne grupy uprzywilejowane, w zależności od charakteru projektu] staje się o wiele prostsze – nie zmuszamy użytkowników do ponownej nauki ułożenia elementów i ogólnej logiki działania aplikacji [zakładam, że panel administracyjny w pierwszym wariancie to aplikacja oderwana od "rzeczywistości" samej strony zarządzanej - przede wszystkim inny layout]. Jest to rozwiązanie nieco trudniejsze i wymagające większego nakładu pracy, może też powodować trudności z wprowadzaniem istotnych aktualizacji, ze względu na to, że logika działania obu elementów [panelu i strony] jest ze sobą ściśle powiązana. Podsumowując:
- Łatwiejsze korzystanie z funkcjonalności panelu.
- Bardziej zwarta struktura całości.
Podsumowanie.
Szczerze mówiąc od pewnego czasu jestem „kuszony” przez ten drugi wariant, szczególnie ze względu na bardzo ładnie wyglądającą interakcję pomiędzy oboma elementami całego projektu, ale kiedy biorę pod uwagę czas pracy i ewentualne późniejsze problemy z rozbudową, decyduję się jednak na wykonanie oddzielnego skryptu [wariant pierwszy].
Chciałbym jednak poznać Wasze zdanie na ten temat, szczególnie miło byłoby, gdybyście opisali konkretne rozwiązania z Waszego doświadczenia i skutki, jakie pociągnął za sobą określony wybór. Jeśli masz inny pomysł na rozwiązanie sprawy – także będę wdzięczny za podzielenie się spostrzeżeniami.
Warto przeczytać.
Trwa ładowanie…
Czy jeśli mam panel front-end dla zwykłych userów oraz panel back-end dla adminów to jest to Wariant 1 ?
Dokładnie tak, po prostu panel administracyjny jest oddzielną aplikacją – umieszczasz ją np. w domena.com/admin albo admin.domena.com i wtedy nie ma „nic” wspólnego ze stroną zarządzaną, tylko dokonujesz modyfikacji danych, które ona wyświetla. W drugim wariancie panel administracyjny TO jest strona, którą zarządzasz. ;]
Ciekawypis. Jeszcze dodatkowym wariantem może być albo wymieszanie tych dwóch np przez umieszczanie tylko linków odsyłających do podstron bez odizolowanego systemu. Albo (sądzę, że zalicza się to do pierwszego) można stworzyć zwyczajna aplikacje desktopową.
Osobiście wykorzystuję przedstawiony przez Ciebie wariant I
Artykuł jest nieco stronniczy, bo wynika z niego prawie jednoznacznie, że wariant oddzielnej aplikacji jest lepszy, ale chciałem poznać zdanie czytelników – może ktoś ma jakieś ciekawe wnioski. Tutaj przedstawiłem dwie skrajne opcje i wygląda na to, że chyba „Ameryki” nie odkryjemy. ;]
Przeczytałam, pomyślałam przez chwilę i doszłam do takiego wniosku: wszystko zależy od projektu i oczekiwań zleceniodawcy. Jeżeli jest to panel administracyjny służący np. do zarządzania użytkownikami, moderowania wpisywanych treści przez użytkownika, generalnie wszystkiego, co nie wiąże się z wprowadzaniem/zmianą za pomocą panela treści strony, to oddzielna aplikacja jest w takim przypadku wskazana. Jeżeli natomiast panel ma również służyć do zmiany treści strony, to biorąc pod uwagę pracochłonność systemu, jego złożoność oraz tego, że to wszystko musi się zgrywać (no i parę innych aspektów) – jednak chyba lepszym rozwiązaniem jest panel zintegrowany z aplikacją, ale jedynie do celów zmienienia zawartości strony. Widziałam również panel, gdzie logowałam się na stronie internetowej jako użytkownik, w tym momencie następowało logowanie automatyczne do panelu zewnętrznego. Czy jest to połączenie obu paneli?
Dziękuję za bardzo bogaty merytorycznie komentarz. Obecność kobiety na moim blogu jest wysoce budująca [oczywiście bez żadnych podtekstów, po prostu się cieszę]. ;]
Rozwiązanie, które opisałaś na końcu to przypadek, którego nie przewidziałem, bo wynika z ciekawie zaprojektowanej struktury strony. Ja bym to rozpatrywał jako wariant oddzielnej aplikacji, ponieważ oba elementy są połączone praktycznie tylko danymi sesji [najprostszy sposób], która uwierzytelnia nas w obrębie całego projektu, ale strona i panel pozostają oddzielnymi tworami.
No dobrze, a co w takim razie z oceną bezpieczeństwa takiego logowania? Wiem, że są naprawdę biegli ludzie, dla których praktycznie nie ma zabezpieczeń nie do złamania, ale biorąc pod uwagę przeciętny wiek użytkowników tego serwisu to jest, jak na moją logikę, jak zostawienie tabliczki przed domem „Spróbuj mnie okraść”. Pomijam już kwestię tego, jak sam dom jest zabezpieczony. W końcu takiemu zwykłemu zjadaczowi chleba można jednak utrudnić znalezienie chociażby adresu do tego domu. Tak mi się metaforycznie trochę zrobiło, ale mam nadzieję, że zrozumiale.
Widzę, że ambitnie podchodzisz do tematu, więc postaram się zaspokoić Twój głód wiedzy. ;] Co do bezpieczeństwa – ja mogę się wypowiadać wyłącznie na temat bezpieczeństwa kodu w np. PHP, bo na pewno się zgodzisz, że jak ktoś przełamie zabezpieczenia serwera, czyli „rozwali” całą fasadę działania skryptu, to nawet najlepsze filtrowanie danych i inne walidacje nie pomogą. Od tego są administratorzy, żeby patrzeć na serwer jako maszynę, od tego są programiści, żeby pisać bezpieczne skrypty i nie umożliwiać przez swoje błędy żadnego ataku.
Nie rozumiem tylko co masz na myśli mówiąc o utrudnianiu znalezienia adresu domu – logowanie następuje po stronie serwera, więc o ile w menu nie ma po prostu linka „przejdź do panelu admina”, to użytkownik raczej go nie znajdzie. Z drugiej strony ukrywanie panelu przez odpowiedni adres też nie jest zbyt optymalne, bo to tylko ukrywanie a nie zabezpieczenie. Tak więc bezpieczeństwo tego systemu zależy tylko i wyłącznie od dobrego systemu uprawnień, który wykryje który użytkownik ma możliwość wejścia do panelu, a który nie.
Jeśli nie czujesz, że odpowiedziałem dokładnie na to, co chciałaś, to sprecyzuj nieco tą sytuację, bo tak jak mówię, nie do końca rozumiem „ukrywanie adresu domu”.
Oczywiście zgadzam się, że od tego są administratorzy i programiści, aby panel był maksymalnie bezpieczny. Przez ukrywanie adresu mam na myśli tworzenie specjalnej struktury folderów (folder w folderze, który jest jeszcze w innym folderze) oraz odpowiednie zabezpieczenie przez wylistowaniem katalogów na serwerze. Niejednokrotnie przeglądając strony w Internecie próbuję się dostać do podkatalogów. Wiele razy mi się to udaje, gdyż nie wszyscy właściciele stron słyszeli o htaccess. A czasem jak widzę zawartość tych katalogów, to zdecydowanie stwierdzam, że taka wiedza by się przydała.
To nie jest głód wiedzy, bo takową posiadam, może trochę okrojoną, ale zawsze. To jest raczej wymiana poglądów. W końcu co dwie głowy, to nie jedna :)
Proste. :) W każdym razie tak jak napisałem, ukrywanie samego adresu nie jest zbyt optymalną formą zabezpieczenia, bo ktoś kto go zna automatycznie jest jeden poziom „wyżej”. I lepiej nie łudzić się, że jak ktoś zrobi „http://mojastronka.com/mój/strasznie/ukryty/panel.php” to nikt się nie domyśli / nie znajdzie tego. Zabezpieczenia strony powinny polegać głównie na niemożności ich złamania, czyli obronie przed SQL Injection, XSS, XSRF i innymi tego typu. Tak więc zrobienie bardzo skomplikowanej struktury katalogów nie chroni nas przed niczym. A pliki .htaccess i zabezpieczenia przez listowaniem katalogów potrzebne są swoją drogą. ;]