Mariusz Tarnaski "MariuszT"

Na temat przekierowań 301 napisałem już sporo (tu i tu) ale tym razem mam coś bardzo smakowitego

Przekierowania 301 najczęściej używa się gdy chcemy aby nasza strona zawsze pojawiała się z lub bez „www”. Oczywiście podawałem już rozwiązania tego problemu w .htaccess (patrz linki wyżej) ale miały one jedną wadę: trzeba było wpisać adres swojej witryny. A może da się prościej? Czytaj dalej »

Żeby była jasność: chodzi tu o Windows – Apache – MySQL – PHP Jeżeli nie wiesz co to jest to ten wpis Cię nie zainteresuje i nie czytaj dalej

Kiedyś wszystko instalowałem i konfigurowałem osobno ale jakiś czas temu skorzystałem z wygodnego pakietu XAMPP, który ma jedną niepodważalną zaletę: łatwo się przełączyć między PHP4 i PHP5. A kiedyś tego potrzebowałem…

No więc do niedawna wszystko śmigało ale ostatnio miałem dwa problemy i pomyślałem, że je opiszę, może komuś w ten sposób pomogę.
Czytaj dalej »

Zdaję sobie sprawę, że informacje o przekierowaniu 301 to nic nowego. Ale nadal niektórzy szukają odpowiedzi na pytanie „Co to jest?” więc zamieszczam krótką ściągawkę.

„Przekierowanie 301: Moved Permanently” przydaje się do pozycjonowania stron Internetowych. Służy ono do przekierowania z jednego adresu na drugi. Niby nic nadzwyczajnego ale… To konkretne przekierowanie ma pewne zalety. Otóż przenosi ono „siłę” jednego adresu na drugi. Czyli przekazywany jest PageRank adresu, jego pozycja w wyszukiwarkach na wybrane frazy itd. Czytaj dalej »

Sesje to bardzo przydatny mechanizm i chyba nikogo nie trzeba do tego przekonywać. Opisywany dzisiaj problem tak naprawdę nie dotyczy bezpośrednio sesji. Mimo to, to właśnie podczas pracy z sesjami ludzie najczęściej wykrywają problem.

Logując użytkownika na naszej stronie jesteśmy przekonani, że na każdej podstronie trzeba wystartować sesję i już mamy załatwiony problem przenoszenia informacji o użytkownikach podczas poruszania się po naszej witrynie. Niestety, nie zawsze.

Identyfikator sesji można przekazywać między stronami na dwa sposoby: poprzez plik cookie lub za pomocą adresu URL. Pierwszy jest wygodny ale zapisywanie ciasteczek może być wyłączone przez użytkownika. Drugi jest kłopotliwy. PHP samo dba o doklejanie identyfikatora do wszystkich adresów ale ten mechanizm nie jest w stanie wykryć wszystkich dziwnych sytuacji i czasami sami musimy mu dopomóc. Ponadto metoda ta zwiększa zagrożenie przejęcia aktywnej sesji przez inną osobę.

Na szczęście niewiele osób wyłącza ciasteczka i raczej wszyscy programiści skłaniają się do pierwszej metody.

Problem pojawia się gdy nasza strona ma adresy w subdomenach np. abc.tarnaski.eu. Dla naszej przeglądarki to jest zupełnie inny adres od samego tarnaski.eu (nawet www.tarnaski.eu i tarnaski.eu to tak naprawdę dwa różne adresy) i nie przekazuje dalej ciasteczka z identyfikatorem sesji. Można jednak temu zaradzić.

Każdemu ciasteczku możemy ustawić parametr, który podpowiada przeglądarce dla jakiej domeny dane ciasteczko jest widoczne. Oczywiście przeglądarki zabezpieczają się przed ustawieniem ciasteczka dla zupełnie obcej domeny. Nie możemy zmieniać ciastek na komputerze użytkownika, które zostały ustawione przez inne strony www. To byłaby straszna luka bezpieczeństwa. Możemy natomiast rozporządzać własną domeną.

Domyślnie każde ciastko jest dostępne tylko i wyłącznie dla adresu domeny z której to ciastko zostało wywołane. Jeżeli więc ustawimy ciastko z adresu tarnaski.eu to wchodząc na adres abc.tarnaski.eu przeglądarka nie przekaże naszemu serwerowi informacji o ciasteczku. W przypadku sesji, identyfikator nie będzie znany i PHP uzna, że ten użytkownik dopiero wszedł na naszą stronę i wygeneruje nowy SID.

Możemy to jednak zmienić. Dla sesji istnieje specjalna funkcja, która pozwala nam ustawić parametry naszego ciasteczka sesyjnego. Nazywa się session_set_cookie_params(). Poniżej prezentuję przykład użycia:

Dokładniejsze informacje o tej funkcji znajdziesz w manualu. Nas w tej chwili interesuje trzeci parametr. Oto rozwiązanie zagadki. Należy ustawić tu naszą domenę z kropką na początku. To jasna informacja dla przeglądarki, że ciastko ma być dostępne dla domeny głównej i dla wszystkich subdomen. Od teraz Twoi użytkownicy nie będą wylogowywani gdy będą poruszali się między subdomenami Twojej witryny.

Tak jak napisałem na początku, problem dotyczy nie tyle sesji co mechanizmu ciasteczek. Pamiętaj o tym bo być może w przyszłości będziesz chciał przekazać między subdomenami jakieś własne ciastko. Mechanizm zachowania jest identyczny tylko domenę ustawiasz bezpośrednio w funkcji setcookie().

Ciekawostka
Istnieją inne sposoby ustawienia domeny dla ciastka sesyjnego. Jeżeli masz dostęp do uruchamiania funkcji ini_set() to możesz użyć takiego kodu:

Natomiast z poziomu pliku .htaccess (oczywiście potrzebne są odpowiednie uprawnienia, nie na każdym hostingu to zadziała) możesz zrobić to:

Czasami zdarza się, że chcemy ustawić dostęp na hasło do wybranego katalogu i podkatalogów lub do całej strony www. Można się bawić w PHP ale nie zawsze to jest proste (zależy od budowy serwisu) i nie zablokujemy w ten sposób dostępu do plików graficznych, CSS itd. czyli do wszystkich, których nie interpretuje PHP przy ich wywołaniu.

Jest jednak prosta metoda dla użytkowników Apache. W pliku .htaccess wstaw gdzieś taką treść (jeżeli nie masz tego pliku to go stwórz):
AuthName "Podaj haslo"
AuthType Basic
AuthUserFile /SCIEZKA_DO_KATALOGU/.htpasswd
Require valid-user

SCIEZKA_DO_KATALOGU zamień na poprawną ścieżkę do katalogu w którym będzie plik .htpasswd, który zaraz utworzymy. Pamiętaj aby ten plik, o ile to możliwe, był poza głównym katalogiem aplikacji czyli aby nie był dostępny bezpośrednio z przeglądarki. Z doświadczenia wiem, że z tą ścieżką mogą być problemy bo ludzie ustawiają ją względem swojego najwyższego katalogu do którego mają dostęp a to najczęściej błąd. Najłatwiej w jakimś pliku PHP wywołać taką linijkę:

To podpowie Ci gdzie tak naprawdę znajduje się Twoje konto w strukturze katalogów serwera i na podstawie tej informacji ustaw ścieżkę. Można też próbować zabawy ze ścieżkami względnymi (np. ../.htpasswd) ale nie zawsze to działa.

Plik .htpasswd to nic innego jak zwykły plik tekstowy z zapisanymi hasłami. W jednej linijce mieści się informacja o jednym użytkowniku, w takiej formie:
uzytkownik:haslo

Hasła w .htpasswd są specjalnie zakodowane. Pod tym adresem znajdziesz generator haseł. Dla loginu MariuszT i hasła haslo może to wyglądać w ten sposób:
MariuszT:$apr1$53lRO/..$KTQqShXUgmYUotpueXfyg0

Po zapisaniu wszystkiego i wejściu na adres, który ma być chroniony, wyświetli nam się monit o podanie hasła. Nie zostaniemy wpuszczeni dalej póki nie podamy prawidłowych danych. Jeżeli anulujemy monit to dostaniemy błąd 401: wymagana autoryzacja. Jeżeli wpiszemy poprawne login i hasło to wyświetli się nam docelowa strona i przechodząc na inne podstrony nie musimy już ponownie podawać danych autoryzacyjnych.

Ciekawostki:

• Generowanie haseł jest w taki sposób zaprojektowane, że dla jednego loginu i hasła będą Ci się generować inne hashe.
• W systemach Windows domyślnie do generowania haseł używa się MD5 natomiast w Linuxach Crypt. Tylko hasła zahashowane przez MD5 działają na obu systemach.
• Nazwę pliku .htpasswd możemy ustawić na inną w konfiguracji serwera. Stanowczo jednak odradza się to robić ponieważ pliki zaczynające się od .ht są domyślnie chronione przez Apache i dostęp do nich jest blokowany przy każdej próbie wywołania z zewnątrz (np. z przeglądarki). Jeżeli zmienimy nazwę pliku na inny to sami będziemy musieli się zatroszczyć o to aby ten plik był chroniony. Oczywiście hasła są zakodowane więc nawet jeżeli ktoś dostanie się do tego pliku to nadal ich nie odczyta ale może użyć metody brute force do poznania hasła.