.png "PHP i Windows - Instalacja środowiska"){kind=icon}
.png "PHP i Windows")
.png "PHP i Windows - SQL Server Driver for PHP"){kind=icon}
PHP i Windows - Przyjazne linki na serwerze IIS .png "Udostępnij na: Facebook")
Autor: Maciej Wilgucki
Opublikowano: 2011-07-05
Przyszło nam tworzyć aplikacje internetowe w czasach, gdy link o postaci do=update&id=123 jest co najmniej passé. Od dłuższego czasu jesteśmy przekonywani do tworzenia tzw. przyjaznych linków. W przypadku serwera Apache ich wykorzystanie jest banalnie proste i sprowadza się do użycia modułu mod_rewrite. Do zapisania reguł definiujących ładne linki najczęściej wykorzystuje się plik .htaccess. Przesiadka na IIS nie musi wcale oznaczać konieczności rezygnacji z przyjaznych linków, na serwerze Microsoftu mamy bowiem do dyspozycji moduł URL Rewrite oferujący takie same możliwości jak mod_rewrite w Apache.
Instalacja
Instalacja modułu jest niezwykle prosta i sprowadza się do wykorzystania dobrze już znanego Web Platform Installera. Niestety, w polskiej wersji językowej nie znajdziemy w nim URL Rewrite, ponieważ został przetłumaczony na Ponowne zapisywanie adresów URL w wersji 2.0. Możemy go znaleźć w sekcji Serwer w kategorii Produkty (rysunek 1).
.jpg "Moduł URL Rewrite w Web Platform Installer")
Rys. 1. Moduł URL Rewrite w Web Platform Installer.
Instalacja odbywa się w identyczny sposób, jak w przypadku produktów instalowanych w poprzedniej części – klikamy w przycisk Dodaj obok nazwy produktu oraz Zainstaluj w dolnej części okna Web PI, a następnie postępujemy zgodnie z poleceniami wyświetlanymi na ekranie.
Tworzenie reguł
Po zainstalowaniu URL Rewrite możemy przejść do tworzenia reguł. Możemy to robić na cztery sposoby.
Edytor graficzny
Najprostszym sposobem na utworzenie wymaganych przez nas reguł jest skorzystanie z graficznego edytora zdejmującego z naszych barków obowiązek znajomości struktury pliku konfiguracyjnego (o którym nieco więcej dowiemy się w dalszej części dzisiejszego artykułu).
Aby skorzystać z edytora, musimy uruchomić najpierw Menedżera internetowych usług informacyjnych (IIS), a następnie wybrać witrynę, dla której chcemy utworzyć ładne linki. Kolejnym krokiem jest przejście do modułu URL Rewrite (rysunek 2).
.jpg "Wybór modułu URL Rewrite")
Rys. 2. Wybór modułu URL Rewrite.
W centralnej części okna, która aktualnie jest pusta, zobaczymy nasze reguły. Po prawej natomiast znajdują się akcje, jakie możemy wykonać w związku z regułami. Nas interesuje akcja Add Rule(s)…. Po jej wybraniu pojawi się nowe okno z możliwością wyboru kilku opcji, a pośród nich taka, która nas najbardziej interesuje, czyli User-friendly URL (rysunek 3).
.jpg "Wybór rodzaju nowej reguły")
Rys. 3. Wybór rodzaju nowej reguły.
Wybranie wskazanej opcji spowoduje pojawienie się kolejnego okna, które pozwala na wprowadzenie „brzydkiego adresu” oraz wybranie jego ładnego (przyjaznego) odpowiednika (rysunek 4).
.jpg "Edytor przyjaznych linków")
Rys. 4. Edytor przyjaznych linków.
Po kliknięciu OK nasza reguła zostanie zapisana, a my możemy cieszyć się ładnymi linkami w serwisie.
Zaawansowany edytor graficzny
Zaawansowany edytor graficzny to tak naprawdę ten sam edytor, z którego korzystaliśmy przed chwilą, z jedną drobną różnicą. Sami definiujemy wszystkie reguły, zmienne serwera oraz określamy co i w jaki sposób zostanie „przepisane” bądź przekierowane.
Do wyboru mamy kilka predefiniowanych schematów podzielonych na logiczne grupy: przychodzące, wychodzące, przechodzące i wychodzące oraz SEO. Jeśli chcemy własnoręcznie utworzyć regułę dla przyjaznych linków, wybieramy opcję Blank rule w grupie przychodzące (rysunek 5).
.jpg "Tworzenie nowej pustej reguły")
Rys. 5. Tworzenie nowej pustej reguły.
Po wybraniu wskazanej opcji uruchomiony zostanie edytor (rysunek 6) pozwalający zdefiniować wszystkie możliwe aspekty reguł. Edytor został podzielony na cztery sekcje, odpowiedzialne za inną część reguły.
.jpg "Edytor reguł")
Rys. 6. Edytor reguł.
Pierwsza sekcja – Match URL – służy do określenia wzorca, według którego adres będzie sprawdzany. Druga (Conditions) pozwala na określenie dodatkowych warunków, które muszą być spełnione, aby adres został „przepisany”. Do dyspozycji mamy cały szereg zmiennych serwera, takich jak QUERY_STRING, REMOTE_ADDR i wiele innych. Kolejną sekcją jest Server variables – umożliwia ona ustawienie dowolnej zmiennej serwera i zwrócenie jej w odpowiedzi. Ostatnią sekcją jest Action, czyli akcja, jaka ma nastąpić w efekcie dopasowania żądania. Żądanie można „przepisać” na zrozumiały dla aplikacji ciąg, przekierować, przerwać lub wysłać niestandardową odpowiedź.
Importowanie pliku .htaccess
Jeśli posiadamy działającą na serwerze Apache aplikację i chcielibyśmy przenieść ją na IIS, nic nie stoi na przeszkodzie, aby obok samej aplikacji przenieść reguły z pliku .htaccess. Moduł URL Rewrite oferuje narzędzie do importowania reguł zapisanych w pliku .htaccess do formatu czytelnego dla serwera IIS.
W celu zaimportowania pliku .htaccess należy wybrać opcję Import rules w akcji Inbound rules w Menedżerze internetowych usług informacyjnych (IIS). Zostanie nam wyświetlony edytor służący do importowania reguł (rysunek 7). Jedyne, co musimy zrobić, to wskazać położenie pliku .htaccess i kliknąć przycisk Import. Edytor sam rozpozna reguły i je przetłumaczy. Jeśli pojawią się jakieś błędy, zostaną one pokazane w oknie podsumowania.
.jpg "Importowanie pliku .htaccess")
Rys. 7. Importowanie pliku .htaccess.
Ręczna edycja pliku web.config
Ostatnim sposobem tworzenia reguł jest ręczne uzupełnienie pliku web.config. Zanim jednak do tego przejdziemy, powinniśmy dowiedzieć się co nieco o wspomnianym pliku. Web.config jest podstawowym plikiem konfiguracyjnym aplikacji działającej na serwerze IIS. Umożliwia on skonfigurowanie każdego aspektu naszej aplikacji. W dużym uproszczeniu działa on na podobnej zasadzie jak plik .htaccess i tak samo można go umieszczać w podkatalogach, powodując tym samym modyfikację ustawień w obrębie jednego katalogu. W przeciwieństwie do pliku .htaccess, web.config jest dokumentem XML.
Każde ustawienie zawarte w pliku web.config musi znajdować się w odpowiednim węźle. W przypadku modułu URL Rewrite węzłem tym jest rewrite, który należy umieścić w węźle system.webServer. Wszystkie reguły przychodzące znajdują się w węźle potomnym wobec węzła rewrite o nazwie rules. Pojedyncza reguła zaś jest potomkiem węzła rules i nazywa się po prostu rule.
Każda reguła musi posiadać nazwę. Opcjonalnym atrybutem jest stopProcessing, określający, czy po dopasowaniu reguły dalsze przetwarzanie reguł ma się zakończyć. Jego odpowiednikiem z Apache’a jest flaga L dodawana na końcu reguły. Kolejnymi elementami reguły są węzły będące odpowiednikami sekcji opisanych wcześniej w rozdziale „Zaawansowany edytor graficzny”. Mamy tutaj węzeł match wraz z atrybutem określającym wzorzec dopasowania, węzeł conditions zawierający w węzłach potomnych nazwy testowanych zmiennych serwera wraz z porównywanymi wartościami, węzeł serverVariables ustawiający zmienne serwera oraz węzeł action, czyli akcja wykonywana w przypadku dopasowania reguły.
Odbieranie danych
Odbieranie danych przesyłanych w przyjaznych linkach na serwerze IIS nie różni się niczym od odbierania danych na serwerze Apache. W obydwu przypadkach dane przepisane z ładnego linka znajdą się w zmiennej globalnej $_GET. Dzięki temu my, jako programiści, nie musimy nic zmieniać w naszej aplikacji, jeśli chcielibyśmy ją przenieść z serwera Apache na serwer IIS.
Podsumowanie
Dzisiejszy artykuł przybliżył nam mechanizm przyjaznych linków na serwerze IIS. Jak się przekonaliśmy, tworzenie reguł nie musi wiązać się z ręczną edycją jednego z najważniejszych plików na serwerze. Doskonałym uzupełnieniem dzisiejszego artykułu będzie zbiór przewodników po URL Rewrite, który można znaleźć pod adresem http://learn.iis.net/page.aspx/734/url-rewrite-module/.