Na pewno wpadliście kiedyś w pułapkę, w której podczas testowania wydajności / sposobu działania wpisaliście w okienko phpMyAdmina lub bezpośrednio w konsolę MySQLa nie do końca przemyślane zapytanie. Jeśli zawierało jakiś błąd składniowy, to sprawa jest prosta - na ekranie szybko pojawił się błąd. Co jednak w przypadku tych zapytań, które “mieliły się” przez dobre kilkanaście minut lub po prostu nie miały szans na zakończenie (w sensownym czasie) ze względu na dostępne zasoby systemowe? Jeśli zechcecie przeczytać niniejszy artykuł, powiem Wam co można z tym zrobić.
Ostatnio miałem okazję zająć się bardziej poważnie administracją serwera (dokładniej VPSa) “od podstaw”. Od podstaw, to znaczy na zupełnie zerowej instalacji Linuksa, w związku z czym trzeba było zainstalować, skonfigurować i uruchomić wszystkie niezbędne do pracy usługi. Pomimo tego, że generalnie określiłbym się jako programista mający od czasu do czasu do czynienia z zagadnieniami administracyjnymi poszło mi to całkiem nieźle - po kilku godzinach wszystko śmigało bez żadnych problemów, a ja mogłem wrócić do kodowania. Oczywiście nie obyło się bez problemów, dlatego jedną ze znalezionych, raczej prostych przypadłości opisuję dzisiaj na blogu.
Od dłuższego czasu jestem bardzo zadowolonym użytkownikiem systemu zarządzania projektami Redmine. Pomimo tego, że jest on napisany w Ruby, używa się go bardzo wygodnie, w miarę bezproblemowo można go także skonfigurować według własnych wymagań. Jednym z problemów jest jednak dosyć niestandardowe rozmieszczenie linków do niektórych funkcji systemu, przez co o niektórych możliwościach nie wiemy lub dowiadujemy się przypadkiem. W moim przypadku takie “przypadkowe” trafienie na stronę zawierającą interesujące ustawienia zdarzyło się dzisiaj z samego rana, a więc jeszcze ciepłe przekazuję Wam.
Problemy, jakie napotykamy podczas programowania wszelkiego rodzaju aplikacji można podzielić na dwie główne kategorie - wymagające doświadczenia i wymagające wiedzy. O ile te związane z doświadczeniem można rozwiązać bez pomocy innych - rozwiązania można po prostu wywnioskować na podstawie doświadczenia, o tyle związane z wiedzą nie są takie proste. Ich rozwiązanie to zdobycie informacji o tym, co należy zrobić, żeby było dobrze, a do rzeczonej informacji czasem bardzo ciężko się dostać. W dzisiejszym wpisie chciałbym właśnie dla swojej i Waszej referencji opisać jeden problem związany z “wiedzą” w symfony.
Programiści wielkich aplikacji stoją przed dużym wyzwaniem - muszą dogodzić jak największej liczbie użytkowników, minimalizując grupę tych, którym tworzone przez nich nowości zwyczajnie nie pasują. O ile w przypadku oprogramowania zamkniętego sprawa jest nieco prostsza, bo użytkownicy czują się bardziej przywiązani do filozofii programu, za który zapłacili, o tyle wolne oprogramowanie musi cały czas o rzeczonego użytkownika walczyć. Na szczęście, jeśli ktoś “zna się na rzeczy”, może zmienić działanie danej otwartoźródłowej aplikacji, ponieważ cała idea OSS polega na tym, że każdy może co mu się podoba. ;] W przypadku Firefoksa byłem istotnie przyzwyczajony do przycisku zamykania ostatniej zakładki, który “czyścił” ją, nie zamykając okna programu. W jednej z poprzednich wersji ta funkcjonalność niestety nie spodobała się twórcom i została nie wiedzieć czemu wyrzucona. W dzisiejszym wpisie chciałbym pokazać, jak zrobić na przekór programistom z Mozilli i przywrócić stare zachowanie najlepszej z przeglądarek. ;]
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.
Od dłuższego czasu korzystam z hostingu wykupionego w amerykańskiej firmie DreamHost. Pomimo wielu negatywnych opinii, jakie znalazłem na różnych forach i blogach muszę powiedzieć, że jestem całkiem zadowolony ze świadczonych mi usług. W tym momencie przypominam sobie tylko jeden przypadek, kiedy nie miałem dostępu do danych przez około dziesięć minut. Dostęp do serwera poprzez SSH, SVN, możliwość tworzenia własnych serwerów MySQL, nielimitowane parametry konta - słowem cud, miód i orzeszki. Nie znaczy to jednak, że musisz rzucić swojego dotychczasowego dostawcę i przenieść się do DH, aż tak dobrze nie jest ;] Jednym z problemów, jakie napotkałem podczas korzystania z serwera było to, że tworząc konto FTP dla strony internetowej klienta nie mogłem uzyskać do niego [tego konta ;]] pełnego dostępu, inaczej niż przez zalogowanie się przy użyciu jego [tego klienta ;]] danych. W niniejszym wpisie chciałbym przedstawić rozwiązanie na jakie wpadłem podczas pracy.
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].