[APACHE] Konfiguracja HTTPS na localhoście - zabawa z OpenSSL

W artykule tym nauczymy się jak na lokalnym serwerze stworzyć możliwości do obsługi protokołu https://. Pozwoli to nam na lokalne testowanie tych elementów naszej aplikacji, które w wersji produkcyjnej będą działać na połączeniu szyfrowanym. Do stworzenia sobie takiej funkcjonalności potrzebny będzie nam certyfikat SSL, którym konieczne będzie podpisanie naszego serwera. Certyfikaty takie kosztują i są wydawane dla konkretnej domeny przez uprawnione do tego organy, jak np. VeriSign.

My oczywiście nie będziemy kupować żadnego certfikatu dla własnych lokalnych potrzeb - zamiast tego skorzystamy z darmowego pakietu OpenSSL i taki certyfikat wygenerujemy oraz podpiszemy sobie sami. Wiąże się to z pewną małą "niedogodnością" - mianowicie przeglądarki będą pluły nam informacją o tym, iż nasz certfikat jest niezaufany i z niepewnych źródeł ;) Wystarczy jednak to zignorować.

OpenSSL

No to zaczynamy. Pierwszą sprawą jest zaopatrzenie się w darmowy pakiet OpenSSL, który pobierzemy stąd: http://indy.fulgan.com/SSL/. Na Linuxach pakiet ten powinien być dostępny domyślnie, dla Windowsów musimy go pobrać, zróbmy więc to. Wchodzimy na w/w stronę, pobieramy najnowszą dostępną wersję odpowiednią dla naszego systemu (32/64 bity) i rozpakowujemy, np. do:
[code]C:\OpenSSL[/code]

[APACHE] Autoryzacja za pomocą .htpasswd

W Apache'u możemy ograniczyć dostęp do dowolnego katalogu za pomocą ustawienia wymogu autoryzacji. Jest to bardzo przydatna opcja, dzięki której możemy ograniczyć dostęp np. do testowych wersji projektów dla swoich klientów na zasadzie konieczności podania loginu oraz hasła użytkownika. Jest to prosta autoryzacja oparta na dwóch plikach, które w tym artykule przygotujemy - pliku .htpasswd, w którym będziemy przechowywać nasze hasła, oraz pliku .htaccess, który będzie z tego pliku korzystał w celu autoryzacji użytkownika.

O ile jednak plik .htaccess utworzymy w zwykłym notatniku, to już z plikiem .htpasswd będzie więcej zachodu, gdyż tego pliku nie jesteśmy w stanie przygotować "odręcznie". Wynika to z faktu, iż hasła przechowywane w tym pliku zapisywane są w formie szyfrowanej, zatem skorzystać będziemy musieli z jakiegoś narzędzia generującego nasze hasła w formie zaszyfrowanej.

[APACHE] Allow, Deny - konfiguracja dostępu do katalogów

Podczas pracy z serwerem Apache bardzo często spotkamy się z regułami Allow i Deny, które odpowiadają za ustawianie reguł dostępu do danego katalogu z zewnątrz. Reguły te można narzucać globalnie za pomocą głównego pliku konfiguracyjnego Apache'a, można także je nadpisywać w plikach .htaccess o ile na to zezwolimy. Reguły dostępu mają ściśle określoną składnię i warto się z nią zapoznać, aby móc wykorzystywać to w praktyce. Nie jest to trudne i ogranicza się w zasadzie do zrozumienia kilku podstawowych zasad. W tym krótkim artykule postaram się wyjaśnić na czym polega konfiguracja takich reguł, a także kiedy i jak należy je stosować.

Na wstępie musimy mieć świadomość, iż wszystko to co Apache udostępnia "na zewnątrz" może zostać skonfigurowane i określone wg zadanych mu reguł. Poprawna konfiguracja ma kluczowe znaczenie dla bezpieczństwa naszego serwera, a zasada "im mniej udostępniamy w świat, tym lepiej" ma tutaj bardzo duże znaczenie.

Złotą zasadą udostępniania aplikacji na zewnątrz jest wydzielenie odpowiedniej struktury logicznej naszego projektu i podzielenie jej na dwie sekcje: sekcję, która MUSI zostać udostępniona na zewnątrz - szablon strony, pliki CSS, skrypty .js, czy dołączane grafiki oraz na sekcję z właściwym kodem naszej aplikacji, do której po stronie klienta nie powinno być już dostępu. Warto bowiem zauważyć, że to co udostępnione jest klientowi != temu do czego dostęp ma serwer. Ograniczając udostępniane na zewnątrz zasoby, nie ograniczamy zatem naszej aplikacji, gdyż po stronie serwera ma ona wciąż dostęp do całości kodu ukrytego przed użytkownikiem. Przykładem moze być tutaj popularny framework Symfony, który na zewnątrz udostępnia jedynie folder web/, natomiast cała logika aplikacji znajduje się w folderach powyżej, nie udostępnionych przez WWW.

[APACHE] Jak stworzyć i skonfigurować VirtualHosta?

Vhosty do bardzo wygodny mechanizm do pracy z Apachem. Pomijając już nawet zastosowania typowo produkcyjne, są świetnym ułatwieniem podczas tworzenia środowisk testowych dla swoich webowych aplikacji. Zdejmują nam ograniczenie jednego katalogu głównego dla aplikacji pozwalając na tworzenie wielu różnych środowisk w obrębie jednego katalogu głównego. Przydają się też podczas testowania przekierowań modułu rewrite, a także podczas pracy z SSL, gdzie możemy wydzielić sobie oddzielną poddomenę na szyfrowaną zawartość.

W tym krótkim przewodniku opiszę procedurę tworzenia takiego vhosta w oparciu o pliki konfiguracyjne Apache'a na Windowsie. Na Linuxach konfiguracja jest analogiczna, ale różni się kilkoma formalnymi zabiegami.

Czym jest wirtualny host? Vhost jest aliasem nakładanym na dany katalog na serwerze, do którego to katalogu przypisujemy odpowiednią subdomenę, przy czym katalog taki staje się Document Rootem dla tworzonej subdomeny.
Przykładowo, dysponując lokalnym serwererem localhost z ustawionym Document Root na dajmy na to przykładowo:
[code]C:\WWW\[/code]

[APACHE][mod_rewrite] Reguły, warunki i atrybuty - tworzymy pierwsze praktyczne przekierowania

W poprzedniej części, czyli we wstępie określiliśmy sobie czym jest mod_rewrite, na co mniej więcej pozwala i jak wygląda przykładowa reguła przepisywania adresu. W tym odcinku nauczymy się tworzyć bardziej zaawansowane reguły, które pozwolą już na w pełni określone działanie naszych adresów.

Przy okazji opiszę tutaj kilka standardowych problemów wraz z rozwiązaniami jak sobie z nimi radzić, gdyż mod_rewrite do poprawnego działania wymaga kilku "tricków". Nauczymy się też testowania stworzonych reguł oraz przeanalizujemy atrybuty reguł oraz dostępne w mod_rewrite zmienne.

Na początek małe przepomnienie - reguły określone w pliku .htaccess działają na folder, w którym plik ten się znajduje oraz na wszystkie jego podfoldery (o ile w danym podfolderze nie umieścimy kolejnego .htaccess nadpisującego reguły z pliku nadrzędnego). Na potrzeby tego poradnika nasz .htaccess umieszczamy w katalogu głównym naszego serwera. Przy okazji mały tip: nazwę pliku .htaccess można zmienić na inną dowolną, np. na config - określa się to w konfiguracji Apache'a, radzę jednak pozostać przy domyślnej nazwie, żeby trzymać się standardów.

Środowisko testowe

Na potrzeby nauki powinniśmy przygotować sobie jakieś środowisko testowe.
Moją propozycją jest utworzenie wirtualnego hosta na naszym lokalnym serwerze, tak abyśmy do testowanej strony mieli dostęp z poziomu subdomeny:
[code]rewrite.localhost[/code]
Głównym katalogiem (DocumentRoot) dla vhosta niech będzie np.
[code]/NASZ_GŁÓWNY_KATALOG_Z_WWW/rewrite/[/code]
i to na niego przekierujemy subdomenę rewrite.
Jak stworzyć vhosta opisałem w tym artykule.

[APACHE][mod_rewrite] Wstęp do przepisywania URL-i

Mechanizm przepisywania URL-i za pomocą modułu rewrite z początku może wydawać się nieco skomplikowany. O ile nauczenie się podstawowych regułek przepisywania i wykorzystanie ich w praktyce nie stanowi zbyt dużego problemu, to niestety, ale prędzej, czy później natrafimy na kilka problemów związanych z regułami przekierowań, na pewno też nie raz i nie dwa "zapętlimy się" przy co bardziej rozbudowanej hierarchi regułek.

W artykułach tutaj postaram się przedstawić najczęstsze problemy z jakimi prawie na pewno spotkamy się podczas tworzenia plików .htaccess. Omówię też same podstawy tworzenia takich przekierowań. Zacznijmy więc może od początku - czym jest mod_rewrite? Jest to moduł serwera Apache, ktory za pomocą odpowiednio określonych warunków (conditions) wywołuje zadaną przez nas regułę (rule), która w zadany, określony sposób dokonuje przekierowania z jednego URL-a na inny, zdefiniowany przez nas. Reguły takie określamy w specjalnym pliku o nazwie .htaccess, który umieszczamy w folderze, dla którego zawarte w nim reguły mają obowiązywać (będą też obowiązywać dla jego podfolderów). Plik .htacccess ma ściśle określoną strukturę, składającą się z kilku sekcji. Omówimy je kilka akapitów niżej. Na razie omówmy samą zasadę przepisywania URL-i, a więc - na czym to wszystko polega?

Wyobraźmy sobie, że mamy przygotowaną w PHP aplikację, np. sklep internetowy.
W aplikacji tej posiadamy system kategorii i podkategorii naszych produktów, listę tych produktów, oraz odpowiednie sekcje odpowiadające za wyświetlanie informacji o zadanym produkcie.
Po sklepie tym poruszamy się w jakiś określony sposób definiujący nam np. gdzie obecnie się znajdujemy (czy np. w widoku listy kategorii, czy produktów) oraz jaką kategorię lub produkt obecnie wyświetlamy. Informacje takie przekazujemy zazwyczaj jako parametry w adresie, np.
[code]http://nasz_sklep.com/index.php?action=category&id=20[/code]
lub
[code]http://nasz_sklep.com/index.php?action=product_info&id=45[/code]
Brzydkie prawda? A i niezbyt chętnie indeksowane przez wyszukiwarki.
O wiele ładniej wygladałoby to, gdyby linki przedstawiały się np. tak:
[code]http://nasz_sklep/kategorie/telewizory[/code]
lub
[code]http://nasz_sklep/produkt/Samsung_Smart_LED_J6200.html[/code]

[CHEATSHEET] APACHE2 - MOD_REWRITE

http://overapi.com/mod_rewrite/

[CHEATSHEET] APACHE2 Reference Card

/2 części/

https://googledrive.com/host/0B4Mb4UIYUBbkWXVxMmZ6WEpfNU0

[CHEATSHEET] HTTP - KODY STATUSU

https://googledrive.com/host/0B4Mb4UIYUBbkNGtSel9id3dpeUk