Zapewne wygląda. Znajomo i swojsko! To standardowe podejście, prezentowane w większości samouczków dotyczących autentykacji i autoryzacji. Czasem można spotkać wariacje rodem z horroru, względnie Monthy Pythona, w których uprawnienia, a nawet niezaszyfrowane hasło przekazywane są w cookies.

Tyle tylko, że uproszczenia w tutorialach to jedno, a wymagania produkcyjnych systemów to co innego. Przynajmniej w teorii. W praktyce zdarza się, że taki tutorialowy algorytm prześlizguje się w niemal dosłownej implementacji do skądinąd świetnie pomyślanego i wykonanego serwisu. Tkwi w nim, niezauważany, by w krytycznej sytuacji dać o sobie znać, prezentując z zaskoczenia całą moc swej ułomności.

System

Sporo danych, sporo użytkowników, kilkadziesiąt tysięcy linii doskonale ustrukturalizowanego kodu (nie licząc bibliotek). Przemyślane, profesjonalne rozwiązanie. Kiedy otwieram jego skrypty w edytorze, czuję respekt i symbolicznie chylę czoło w uznaniu dla Autorów. Szacunek budzi także cena tego systemu - ale to już inna sprawa.

Sytuacja

Ze względu na tak zwany czynnik ludzki, pewnego dnia pojawia się pilna potrzeba ograniczenia uprawnień grupie uprzywilejowanych dotąd użytkowników (nazwijmy ich moderatorami).

System ma w panelu administracyjnym odpowiednie formularze i obsługuje je perfekcyjnie. Problem leży w logice (a raczej braku logiki) tej części aplikacji.

Otóż:

• uprawnienia sprawdzane są tylko w momencie logowania się - potem są do końca sesji pamiętane;
• dlatego zmiany uprawnień w konfiguracji konta nie mają wpływu na efektywne uprawnienia osoby, która już jest zalogowana;
• nie przewidziano mechanizmu wymuszenia wylogowania (co byłoby działaniem równie brutalnym, co prostym i skutecznym - ponowne zalogowanie ustawiałoby nowe, zmienione uprawnienia);
• co gorsza, moderatorzy mogą przyznawać uprawnienia kolejnym osobom, a to zaproszenie do zabawy w gonienie króliczka…

Akcja

Trzeba pilnie opanować sytuację - zanim zrewoltowani moderatorzy spowodują szkody.

Możliwości, jakie daje serwis w swoim obecnym kształcie, są dwie: albo odłączenie go, zmiana uprawnień i wyczyszczenie sesji na serwerze, albo swego rodzaju wojna na zapleczu administracyjnym (kto szybciej przeedytuje uprawnienia większej ilości kont) i zostawiające niesmak zabiegi socjotechniczne, skłaniające zalogowanych moderatorów do przelogowania się.

Trzecie rozwiązanie, to poprawki w kodzie. Nanoszenie zmian w mechanizmach autoryzacji, pod presją czasu i na publicznie dostępnym systemie, jest proszeniem się o kłopoty. Ale w tej pożałowania godnej sytuacji będzie wyjściem najrozsądniejszym.

Łata

Z punktu widzenia wydajności sprawdzanie i ustawianie uprawnień przy każdym przeładowaniu strony, każdym odwołaniu AJAX itp. można kwestionować. Ale w takich, jak opisana wyżej, sytuacjach okazuje niezbędne. Można je poza tym ograniczyć tylko do odwołań do części serwisu wymagającej uprawnień do moderacji.

W tym konkretnym przypadku podjęte zostały następujące działania:

• dodano w kodzie serwisu mechanizm porównujący uprawnienia pamiętane w sesji z aktualnymi uprawnieniami konta zapisanymi w bazie danych. W razie wystąpienia różnic sesja będzie niszczona, a użytkownik wylogowywany.
• konta zrewoltowanych moderatorów zostały pozbawione uprawnień.

Sytuacja pod kontrolą?

Tak by się wydawało, ale… wspomniany wyżej czynnik ludzki nie da się przecenić. Kilka godzin po naniesieniu łaty, w systemie jak grzyby po deszczu zaczęły się na nowo pojawiać konta moderatorów. Dlaczego? Bo przynajmniej jedno z pozostawionych w systemie kont było współużytkowane przez kilka osób, a z nich przynajmniej jedna zaczęła tworzyć nowe konta i nadawać im rozszerzone uprawnienia.

Druga łata

Oczywiście nie powinna to być żadna łata, tylko rozwiązanie zaimplementowane w systemie od samego początku. Ale lepiej późno, niż wcale.

• w mechanizmach edycji kont zostaje moderatorom odebrana możliwość dalszego nadawania i odbierania uprawnień;

• w systemie zostaje dodane nowe uprawnienie: managera. Będzie ono odtąd wymagane, by uprawnienia moderacyjne na innym koncie przyznać lub zdjąć. A póki co, nie jest ustawione na żadnym z kont.

Wnioski

1. Nawet perfekcyjny od strony programistycznej system może zawierać błędy logiczne.

2. Sytuacje kryzysowe należy mieć rozwiązane zawczasu.

Na ilustracji: pochodzący z XVI wieku obraz nieznanego naśladowcy Hieronima Boscha „Chrystus wypędzający przekupniów ze świątyni”.

Opis przypadku został zmieniony tak, by uniemożliwić identyfikację serwisu. Niemniej, jeśli ktoś z Szanownych Potencjalnych Klientów dostrzeże w powyższym opisie cechy swojego systemu, jestem do dyspozycji.