Tak jak, obiecałem [no dobra, trochę czasu już minęło ;]], opisuję dziś pierwszy z wymienionych wcześniej rodzajów systemów uprawnień w aplikacjach internetowych, pt. “typy użytkowników / obszary dostępu”. Jest to dosyć proste rozwiązanie, aczkolwiek sprawdza się bardzo dobrze w wielu przypadkach, ze względu na prostotę implementacji i łatwość w administrowaniu nawet bardzo dużymi bazami danych użytkowników. Polega ona na podzieleniu użytkowników strony na dwa typy:

• użytkownik - internauta przeglądający stronę, bez możliwości ingerencji w jej treść.
• administrator - użytkownik "uprzywilejowany", posiadający oprócz możliwości przeglądania także prawa edycji treści.

Klasycznym zastosowaniem są strony internetowe oparte o proste systemy zarządzania treścią [CMS] pozwalające na dodawanie i edycję podstron za pomocą jednego z popularnych edytorów WYSIWYG [FCKeditor, TinyMCE]. Z pomocą takiego systemu można stworzyć np. niezbyt skomplikowaną witrynę informacyjną lub własną wizytówkę internetową.

Każdy, kto zajmuje się programowaniem stron internetowych w zakresie szerszym niż tworzenie szablonów w HTMLu na pewno zetknął się z problemem zarządzania tym, co mogą i czego nie mogą użytkownicy danego systemu. Oczywiście nie mam nic do grafików i im podobnych, bardzo szanuję ich pracę jako człowiek dotkliwie pozbawiony zdolności plastycznych ;], jednak w tym artykule zamierzam skupić się na zgoła innym temacie, jakim jest problem nadawania i obsługi uprawnień w aplikacjach internetowych. Jest to dosyć ważne zagadnienie, ponieważ od niego bezpośrednio zależy bezpieczeństwo naszego skryptu. Idealną sytuacją byłaby taka, w której nasi użytkownicy wiedzieliby, jaki jest zakres ich uprawnień i nawet pomimo udostępnienia niektórych funkcji, w swojej uczciwości nie mieli by nigdy zamiaru utrudnienia życia mającym i bez tego dużo pracy programistom. Jeśli użytkownicy Twojego systemu spełniają te założenia, śmiało możesz zakończyć czytanie na tym zdaniu. ;] Wszystkich, którzy jednak nie mają takiego szczęścia, zapraszam do lektury niniejszego artykułu, w którym opiszę systemy zarządzania uprawnieniami o jakich słyszałem / czytałem, bądź z których sam korzystał[em].

Programiści mają to do siebie, że uwielbiają się bawić. Żaden z nas nie jest do końca takim no-life’em, który potrafi tylko cały dzień patrzeć na tysiące linii kodu, szukając błędu bądź też programując nowe funkcje. Czasem trzeba się też “rozerwać”. ;] Jako, że propozycja oderwania się od ekranu jest zwykle przyjmowana z ciężkim westchnięciem, w cenie jest umiejętność “zabawienia się” pozostając cały czas w “swoim świecie”. Można to robić na różne sposoby, jednym nich, którego przykład opisuję w niniejszym artykule, jest umieszczanie w kodzie nieudokumentowanych funkcji, które mogą być aktywowane wyłącznie przez osoby które o nich wiedzą, bądź dogłębnie przestudiowały źródła projektu.

Programując jedną ze stron internetowych natrafiłem na ciekawy problem. Podczas testowania niektórych funkcji chciałem szybko powtórzyć wysyłanie formularza, tak, aby za każdym razem został dodany do bazy danych nowy rekord testowy. Wypełniłem formularz, zatwierdziłem przyciskiem “dodaj” i voila. Potem kilka razy [F5] i [Enter], aby przeglądarka powtórzyła wysyłanie danych metodą POST. Nie byłoby w tym nic nadzwyczajnego, poza tym, że w pewnym momencie zadziałały zabezpieczenia skryptu przed nieautoryzowanym dostępem i zostałem wylogowany z serwisu bez żadnego wcześniejszego powiadomienia. Myślę sobie: “WTF?”. Ze względu na to, że jestem dosyć cierpliwy w takich sprawach [nie wyobrażam sobie życia niecierpliwego programisty ;]] powtórzyłem poprzednie kroki, za każdym razem z tym samym skutkiem. Klikając zbyt szybko na stronie po prostu traciłem dane sesji, cała tablica $_SESSION była pusta jak /dev/null. Wypadałoby w takim razie przejrzeć kod i ewentualnie zapytać Google, co o tym sądzi. Do rozwiązania problemu wystarczyło to pierwsze, jednak, żeby poznać przyczynę, należało sięgnąć po źródła zewnętrzne.