This post comes from the first version of this blog.
Please send me an email if anything needs an update. Thanks!

Kilka dni temu zechciałem w końcu wypróbować statystyki zbierane przez narzędzie Analog instalowane domyślnie dla każdej domeny na serwerach firmy DreamHost. Do tej pory wystarczały mi te z Google Analytics, ale stwierdziłem, że skoro mam za darmo inny sposób, to dlaczego miałbym nie zobaczyć co oferuje?

Problem.

Problem pojawił się przy dostępie do rzeczonych statystyk. Jako, że dostępne są one pod adresem domeny za którym należy umieścić słowo “stats” - tj. dla mojego bloga jest to [nie próbujcie wchodzić - zabezpieczone hasłem ;]]:

http://blog.kowalczyk.cc/stats
wiele osób zgłaszało ten problem na forum DreamHostu, z tego co widziałem na forum było to też zgłaszane jako błąd serwera obsługującego daną stronę, a rozwiązanie jest stosunkowo proste. Co zatem powoduje problem?

WordPress używa pliku .htaccess to przekierowania wszystkich żądań do własnego interpretera adresów URL. Domyślna zawartość tego pliku jest następująca:

1
2
3
4
5
6
7
8
9

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Jest to powszechnie stosowana praktyka, dzięki czemu dany skrypt PHP jest o wiele bardziej elastyczny - jesteśmy stanie na poziomie kodu manipulować URLenm żądania wysłanego przez użytkownika i na jego podstawie “reagować” produkując odpowiednią zawartość. Ma ona jednak pewien mały minus - absolutnie wszystkie żądania przechodzą przez skrypt PHP, nie jest możliwa jakakolwiek ingerencja w to, “kto” zajmuje się interpretacją samego żądania. Widzimy, że w podanym wyżej pliku .htaccess znajdują się linijki:

1
2

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

Są one właśnie po to, żeby żądania odnoszące się do plików i katalogów mogły być bezpiecznie interpretowane przez serwer, a nie skrypt PHP.

W tym momencie bardzo wyraźnie widać, że cały problem z dostępem do statystyk ogranicza się jedynie do wydzielenia kolejnego obszaru poza “jurysdykcją” skryptu WordPressa. Jak to zrobić?

Rozwiązanie.

Aby uzyskać dostęp do statystyk Analoga należy wprowadzić jedną małą zmianę do pliku .htaccess naszej instalacji WordPressa. Należy odszukać wspomniany na początku blok ograniczony liniami: 
1
2
3

# BEGIN WordPress
(...)
# END WordPress

i pod linijką z RewriteBase wstawić poniższy kod:

1
2
3

RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/failed_auth.html$
RewriteRule ^.*$ - [L]

Całość powinna wyglądać następująco:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/stats/(.*)$ [OR]
RewriteCond %{REQUEST_URI} ^/failed_auth.html$
RewriteRule ^.*$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Teraz możemy już spokojnie wpisać dane logowania i przeglądać statystyki naszej strony. O ile w żadnym wypadku nie narzekam na WordPress Stats, tym bardziej nie mogę tego robić w przypadku Google Analytics, to takie statystyki jakie produkuje właśnie Analog są najbardziej prawdziwe - w końcu serwer “wie” ile danych zostało z niego pobranych. Logów serwera nie oszukasz. ;]

Podsumowanie.

Zaprezentowane rozwiązanie można wykorzystać o wiele szerzej - w podobny sposób, podmieniając ścieżki w klauzuli RewriteCond możemy "odblokować dostęp" do wielu innych skryptów, które żądają pełnej kontroli nad przesyłanymi do nich danymi. Z tego co wiem, skrypty takie jak np. Joomla też potrafią być "zazdrosne" i nie pozwolić na dostęp do niektórych danych na serwerze, stąd możemy je zmusić do polubienia naszych danych dodając odpowiednie warunki w pliku sterującym - .htaccess.

To tyle na dzisiaj - dziękuję, że zechciałeś / zechciałaś zapoznać się z tym, co dzisiaj przygotowałem. Do zobaczenia wkrótce. ;]