Jedną z bardzo przydatnych funkcji języka SQL, szczególnie w dialekcie MySQL, jest możliwość umieszczenia wyrażenia regularnego w klauzuli WHERE, przez co można w bardzo wygodny sposób ograniczyć zbiór rekordów, na którym operuje dane zapytanie. Jest to bardzo przydatne w przypadku pól tekstowych, gdzie mamy bardzo ograniczone pole manewru w kwestii porównywania tego typu wartości. Nie każdy jednak wie, że operator REGEXP domyślnie nie uwzględnia wielkości liter porównywanych ciągów znaków. W niniejszym wpisie chciałbym przedstawić Wam krótką poradę dotyczącą naprawy tego niedociągnięcia.
Jakiś czas temu miałem nieodpartą chęć spróbowania nowych funkcjonalności, jakie wprowadzono w PHP 5.3. Przestrzenie nazw oraz late static binding, to tylko niektóre z bardzo przydatnych nowości - na pewno doceni to niejeden programista. Jednak ze względu na fakt, że życie w moim [naszym? ;]] zawodzie nie jest usłane różami, nawet sama aktualizacja instalacji serwera lokalnego przysporzyła trochę problemów. Jednym z nich jest błąd w plikach konfiguracyjnych, którego naprawę opiszę dzisiaj.
Język SQL kryje w sobie wiele różnych tajemnic, których znajomość może bardzo ułatwić życie programisty. Nawet podczas korzystania z jego zwykłych - “nieprogramowalnych” elementów, takich jak podstawowe zapytania CRUD [mówiąc “programowalne”, mam na myśli wszelkiego rodzaju procedury składowane i im podobne] możemy dowiedzieć się o wielu sztuczkach, które potrafią przeobrazić zwracane wyniki w gotowy zestaw danych gotowy do użycia. Mając w pamięci jeden z moich niedawnych wpisów o zwracaniu numeru rekordu, dzisiaj także chciałbym przedstawić Wam jedną z takich sztuczek.
Kilka dni temu, walcząc z modułem wyświetlającym menu w Joomli trafiłem na dosyć ciekawy problem: jak skonstruować zapytanie do bazy danych tak, aby jedna z kolumn w danych wynikowych została wypełniona kolejnymi numerami zwracanych rekordów? Oczywiście nie muszę mówić, że problem został pomyślnie rozwiązany, a ja zapraszam do lektury niniejszego wpisu.
W ostatnich wpisach z tej serii skupialiśmy się na zarządzaniu uprawnieniami pewnych grup użytkowników naszej aplikacji. Obszary dostępu to nic innego jak podział na dwie sztywne grupy posiadające [lub nie] dostępu do pewnych zabezpieczonych elementów systemu, zaś poziomy to tylko wykorzystanie abstrakcji do złożenia w jednym miejscu wielu obszarów. Opisując te sposoby “celowo zapominałem” o tym, że nie zawsze da się podzielić użytkowników na odpowiednie grupy, ponadto nie zawsze nadane uprawnienia muszą być sztywne - czasem chcemy np. dać dodatkowo jednemu zaufanemu użytkownikowi dostęp do statystyk witryny, albo przeglądania artykułów - wtedy musielibyśmy stworzyć albo oddzielny obszar albo nowy poziom, który notabene zburzyłby dotychczas istniejącą strukturę. Co zrobić z takim problemem?
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.
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.
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].