[PHP, (My)SQL] Systemy uprawnień na stronach internetowych, część 0×02: Poziomy użytkowników.

Przyznaję bez bicia, że od ostatniego wpisu w tej serii upłynęło [zbyt] wiele czasu, za co ponoszę winę jedynie ja, ponieważ dopisywałem po jedno - dwa zdania co jakiś czas, ale ogólnie post “wisiał” na liście szkiców i “grzał ławkę”, nie mogąc się doprosić o solidne dokończenie i wejście na “boisko” strony głównej niniejszego bloga. W związku z tym postaram się dzisiaj i za tydzień zamieścić ostatnie części, tak, aby można było zamknąć temat. Przy tworzeniu kolejnej tego typu serii będę musiał chyba od razu napisać wszystkie części i po prostu publikować je w pewnych odstępach czasu, bo w tym tempie to kolejny wpis ukazałby się pewnie w listopadzie. ;] Ale do rzeczy: w jednym z poprzednich wpisów omówiliśmy najprostszy system zarządzania uprawnieniami, czyli autoryzację na podstawie flagi dostępu do danej sekcji strony. Dzisiaj rozszerzymy to rozwiązanie pozwalając na większą kontrolę i możliwość konfiguracji miejsc, do których ma dostęp nasz użytkownik.

Na czym to polega?

Opisany wcześniej sposób autoryzacji nie jest optymalny, ponieważ w podstawowej wersji pozwala na podzielenie użytkowników na jedynie dwa typy - tych którzy mają dostęp do treści “ukrytych” i tych, którzy muszą się “obejść smakiem”. Wprowadzanie kolejnych kolumn opisanych jako obszary dostępu także nie zdaje egzaminu - przy rozrastającym się systemie musielibyśmy stworzyć tabelę posiadającą kilkadziesiąt, jeśli nie kilkaset kolumn w stylu “allow_[nazwa obszaru]“. Tutaj z pomocą przychodzi nowy pomysł - poziomy użytkowników.

[PHP] Zapisywanie zserializowanych obiektów do sesji i błąd __PHP_Incomplete_Class.

W kwestii obsługi sesji i rodzaju zapisywanych w niej danych programiści PHP dzielą się na dwa skrajne fronty: tych, którzy preferują zapis wyłącznie typów prostych i tych, którzy nie widzą problemu w trzymaniu w niej całych obiektów. Ja stoję murem za typami prostymi, ponieważ wydaje mi się bardziej optymalne zapisywanie tylko niezbędnych informacji, na podstawie których ewentualne obiekty można odtworzyć, pozwala to też na zmniejszenie obciążenia serwera, bo odczytanie sesji wymaga deserializacji [odserializowania? deserializowania? kolejne "ciężkopolskie" słowo...] i parsowania o wiele mniejszego pliku. Jakkolwiek byśmy jednak do tego nie podchodzili, dzisiejszy wpis także może być argumentem in plus dla zapisywania wyłącznie zmiennych typów prostych, ponieważ jak mówi stare programistyczne porzekadło: "Serializujesz obiekty [do sesji]? No to masz problem!". ;]

Problem.

Oczywiście dla równowagi mogę powiedzieć, że osoby podzielające moje zdanie na ten temat także nie należą do tych, które nie mają żadnych problemów z zarządzaniem sesjami, jednak na pewno nie są to problemy aż takiego kalibru / typu. Co mam więc tym razem na myśli? Rozważmy następującą sytuację [zmienne proste]: