This post comes from the first version of this blog.
Please send me an email if anything needs an update. Thanks!

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:

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ą.

Od strony użytkownika mamy zatem względnie statyczną stronę internetową. Strona “administratora” to ponadto możliwość redagowania podstron typu: “O Firmie”, “Oferta”, “Kontakt”, etc, przy czym zwykle “zarządca” jest tylko jeden. ;] Nawet jeśli jest ich więcej, to wszyscy oni mają pełny dostęp do całej zawartości panelu administracyjnego.

Wystarczy tego wprowadzenia, spójrzmy teraz na ten system od strony programisty. Patrząc zatem na projekt jako jego twórcy, widzimy, że perspektywa użytkownika jest tylko pewnym uproszczeniem możliwości poziomu administracyjnego, możemy więc ją [na razie] pominąć. Strona administratora wygląda to trochę ciekawiej, ponieważ oprócz wyświetlania mamy możliwość także dodawania, edycji i usuwania podstron, także, mówiąc żargonem informatycznym, pełen CRUD. My jednak mamy zająć się jedynie problemem dostępu do panelu administracyjnego [ech, jak łatwo jest zboczyć z tematu, jak się siedzi we własnej dziedzinie ;]], może kiedyś opiszę także takie przykładowe skrypty stron. Jako, że dane użytkowników “siedzą” w bazie danych, interesuje nas tabela, która będzie nieco uproszczona, ale wystarczy na zademonstrowanie idei. Zatem:

1
2
3
4
5
6
7

CREATE TABLE `basic_model_users` (
`id` int(11) NOT NULL auto_increment,
`login` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`privileged` tinyint(1) NOT NULL,
PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Jak widać, pola “id”, “login” i “password” są dosyć standardowe. Nas interesuje znaczenie pola “privileged”, ponieważ od niego zależy, jak sama nazwa wskazuje [ang. privileged - uprzywilejowany] to, czy użytkownik będzie miał dostęp do panelu administracyjnego, czy nie. Pole to jest typu:

1

tinyint(1)

A więc, jak można się łatwo domyślić, każda niezerowa wartość będzie skutkowała odblokowaniem “trybu admina”. Oczywiście najlepiej zawczasu ustandaryzować sobie wartości tego pola i przyjąć np. wartości boolowskie - 0 lub 1, bądź skorzystać z typu ENUM lub SET.

Mając działający w ten sposób skrypt można na różne sposoby reagować na fakt posiadania przez użytkownika uprawnień administracyjnych, np. wyświetlać mu dodatkowe odnośniki do odpowiednich “zastrzeżonych” funkcji, bądź też przekierowywać go na inną stronę z której może bezpośrednio wpływać na treść artykułów.

W tytule tego posta zostały zawarte słowa “Typy użytkowników / obszary dostępu”, więc, żeby nie być gołosłownym, napiszę też co nieco o innych, bardziej “kreatywnych” zastosowaniach tego mechanizmu autoryzacji. Typy użytkowników w tym przykładzie mamy dwa, więc temat został omówiony. Jeśli chodzi o obszary dostępu, to należy zauważyć, ze pól takich jak “privileged” może być więcej, a każde z nich może odblokować dostęp do określonych funkcjonalności strony. Możemy zatem stworzyć inną tabelę na podstawie już posiadanej:

sqlCREATE TABLE `sn_basic_model_users_alternate` ( `id` int(11) NOT NULL auto_increment, `login` varchar(255) NOT NULL, `password` varchar(255) NOT NULL, `contributor` tinyint(1) NOT NULL, `editor` tinyint(1) NOT NULL, `maintainer` tinyint(1) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;

Należy zauważyć, ze znikło pole “privileged”, które zostało zastąpione trzema innymi, oznaczającymi konkretną funkcję w systemie. Pole “contributor” oznacza osobę, która ma uprawnienia dodawania elementów na strony, “editor” może je zmieniać, a “maintainer” ma dodatkowo prawo usunięcia tego, co zostało umieszczone przez pozostałych użytkowników. Żaden z nich nie wchodzi sobie w kompetencje, tak więc wszyscy żyją długo i szczęśliwie korzystając z naszej wspaniałej aplikacji internetowej.

To tyle w kwestii pierwszego artykułu opisującego mechanizmy zarządzania uprawnieniami, dziękuję za lekturę i zapraszam na kolejne wpisy poświęcone tej tematyce. Być może uda mi się znaleźć czas na napisanie przykładowego skryptu realizującego materiał zawarty w tym wpisie, więc będę mógł pokazać, jak cały system działa w praktyce.