Jakiś czas temu Disqus wprowadził reklamy w swoim systemie komentarzy i bez mojej świadomej oraz dobrowolnej zgody serwował je użytkownikom odwiedzającym mojego bloga. W tamtym czasie nie miałem za bardzo informacji jak te komentarze zastąpić na statycznej stronie renderowanej przy pomocy Hugo. Jako, że sporo osób narzekało na to, że tutaj nie ma komentarzy, przez co liczba maili, które do mnie docierały, była trochę ponad moje moce przerobowe. Postanowiłem zatem zaimplementować system komentarzy oparty o GitHub Issues, czyli ten mechanizm, z którym prawdopodobnie każdy z nas miał już styczność zgłaszając bug'a (czy też inne zapytanie) twórcom swoich ulubionych linux'owych projektów OpenSource. Okazało się, że przy pomocy API GitHub'a można w dość prosty sposób te komentarze pokazać na blogu ale problem pojawił się w przypadku stron mających setki czy nawet tysiące wpisów już opublikowanych. Jak zatem na takich blogach wdrożyć komentarze GitHub'a, tak by przy okazji nie wyskoczyć z okna o 5 nad ranem?

Sporo użytkowników przeglądających tego bloga zdążyło już zauważyć, że sekcja komentarzy została usunięta. W efekcie czego nie można już komentować żadnych wpisów. Taki zabieg miał miejsce ze względu na fakt, że sporo osób zaczęło mi zgłaszać, że na Morfitroniku pojawiły się reklamy. Wszyscy znają raczej moje zdanie w kwestii serwowania ludziom reklam i mocno się zdziwiłem, że pojawiły się one właśnie tutaj. Ja nikomu żadnego pozwolenia na wykorzystywanie mojego bloga jako platformy reklamowej nie udzieliłem. Okazuje się jednak, że Disqus (bo to jego system komentarzy był tutaj wykorzystywany) nawet nie pofatygował się, by zapytać mnie o zgodę na serwowanie reklam i bezczelnie zaczął je w komentarzach umieszczać. Jak tylko się dowiedziałem, że te reklamy faktycznie w tych komentarzach są oraz, że nie mam żadnego wpływu na to, by je usunąć, to postanowiłem natychmiast wywalić Disqus'a.

Po drobnym dostosowaniu tego bloga, zmieniła się też nieco jego stopka. Problem w tym, że z początku widżety ulokowane na samym dole strony niezbyt współgrały ze sobą wizualnie. Generalnie rzecz biorąc, w stopce mam trzy widżety: ostatnie recenzje, archiwum i chmurę tagów. Można co prawda zmieniać ich kolejność ale z racji że są tylko trzy widżety, to nie idzie ich dobrać tak, by były przyzwoicie wyrównane. Winne są tutaj same tagi, które WordPress domyślnie wyświetla w liczbie 45. By te widżety wyglądały przyzwoicie, trzeba by tych tagów dodać kilka, np. tak ze 20 sztuk ale jak to zrobić? Możemy skorzystać z funkcji wp_tag_cloud() .

Przeglądając sobie ostatnio logi mojego serwera Apache2, zauważyłem tam dziwną aktywność. Jakieś boty czy też inne ustrojstwa próbują od czasu do czasu uzyskać dostęp do formularza logowania tego bloga. Jako, że tutaj mamy do czynienia z WordPress'em oraz ochroną pliku wp-login.php oraz katalogu wp-admin/ za pomocą certyfikatów, to taki bot nigdy nie uzyska dostępu do tych zasobów. Niemniej jednak, te automaty generują zapytania do serwera o zasób login , który z kolei przekierowuje je pod wp-login.php za pomocą kodu 301 lub 302. Moglibyśmy uniknąć tego typu przekierowań zwracając im kod 404 i przy tym odciążając nieco serwer www. W tym krótkim artykule zobaczymy jak tego typu zabieg przeprowadzić.

Co jakiś czas zaglądam sobie do panelu Google Search Console w poszukiwaniu błędów na tym blogu. Do tej pory trafiały mi się pojedyncze przypadki błędnego przekierowania adresu URL. Nic wielkiego, bo wystarczy odszukać dany post i poprawić w nim konkretny link. Niemniej jednak, Google zaczyna mnie drażnić "błędami" odnośnie plików xmlrpc.php oraz wp-includes/wlwmanifest.xml . Oba te pliki są zablokowane na poziomie serwera Apache2 z powodu zagrożeń jakie niesie protokół XML-RPC. Dlaczego zatem mechanizmy Google zwracają błędy? Winna jest tutaj błędna konfiguracja instrukcji dla wyszukiwarek, tj. plik robots.txt . Jakby tego było mało, to w przypadku WordPress'a ten plik jest generowany w locie i fizycznie nie istnieje na serwerze. Jak zatem poddać go edycji? Na to pytanie postaramy się znaleźć odpowiedź w tym wpisie.

Gdy odwiedzamy jakiś blog WordPress'a po raz pierwszy, szereg jego elementów jest buforowanych w cache przeglądarki. W ten sposób pewne pliki, np. .css, .js czy też obrazki, nie są pobierane bezpośrednio z serwera www, bo mamy je lokalnie u siebie na dysku. Takie rozwiązanie zapewnia szybsze załadowanie się strony przez minimalizowanie ruchu sieciowego. Niemniej jednak, jako że te pliki siedzą w cache, to muszą mieć ustawiony pewien czas ważności. Może on być różny, a my możemy go sobie dostosować dla poszczególnych elementów ustawiając im nagłówek Cache-Control, Expires, Last-Modified, czy ETag. Gdy w takim nagłówku określimy wysoką wartość max-age , przeglądarka klienta może przez bardzo długi czas nie być świadoma faktu, że któreś elementy strony uległy zmianie. W efekcie może i pojawiła się nowa wersja pliku .css ale klienci odwiedzający nasz serwis i tak nie zaobserwują żadnej różnicy do momentu wygaśnięcia cache lub też odświeżenia strony z przytrzymanym klawiszem Shift . Możemy jednak dodać numer wersji do określonych plików i uzależnić go od czasu modyfikacji danego zasobu na serwerze. Jeśli zmianie ulegnie plik, klient automatycznie pobierze zmodyfikowany zasób.

WordPress został przetłumaczony na dość sporo języków, w tym też i na język polski. Niemniej jednak, pliki bazowe to nie to samo co pliki różnych dodatków. Dlatego też czasem po zmianie języka na polski, nie wszystkie elementy naszego bloga są przetłumaczone. Nie ma przy tym znaczenia czy ustawialiśmy język podczas instalacji WordPress'a, czy też później z poziomu panela administracyjnego. Taki stan rzeczy nie wygląda zbyt estetycznie i przydałoby się coś z tym zrobić. Jeśli zajrzymy do katalogu wtyczek czy motywów, to zwykle znajdziemy tam pliki .mo oraz .po , które są używane przy tłumaczeniu tekstu z wykorzystaniem gettext. Jako, że motyw, który jest wykorzystywany na tym blogu nie jest przetłumaczony, to postanowiłem go przetłumaczyć i przy okazji opisać ten niezbyt skomplikowany proces.

Jeszcze nie tak dawno temu, rzadko który serwis internetowy wykorzystywał certyfikaty SSL/TLS do zabezpieczenia komunikacji między serwerem, a łączącymi się do niego klientami. W dalszym ciągu jednak notuje się strony bez "zielonej kłódki" ale na szczęście jest ich coraz mniej w naszym otoczeniu. Liczbę tych stron można by z powodzeniem ograniczyć jeszcze bardziej, gdyby takie certyfikaty były za free, łatwe do zaimplementowania i dostępne praktycznie dla każdego od tak. No i na dobrą sprawę są, tylko ludzie jeszcze nie zdają sobie z tego sprawy. Istnieje bowiem projekt Let's Encrypt, który umożliwia stosunkowo bardzo proste wdrożenie certyfikatu na serwerze www opartym, np. o oprogramowanie Apache2. W tym wpisie zobaczymy jak ta cała procedura implementacji certyfikatu SSL/TLS przebiega.

Za wysokie uprawnienia zawsze prowadzą do problemów, zwłaszcza, gdy w grę wchodzą komputery i serwisy www. Wszyscy wiemy, że WordPress nie należy do bezpiecznych rozwiązań, mimo, że cała masa stron na necie opiera się właśnie o tego CMS'a. Można jednak wypracować sobie bezpieczny setup, pod warunkiem, że będziemy się zawsze kierować jedna prostą zasadą. Mianowicie chodzi o ograniczenie uprawnień. Standardowo WordPress ma zdefiniowanego jednego użytkownika w pliku wp-config.php , którym skrypt się posługuje. Zwykle też ten użytkownik ma wszystkie możliwe prawa do wszystkich tabel w bazie danych naszego bloga czy serwisu. Nie musi tak być, a my możemy wykorzystać kilku użytkowników i nadać im inne uprawnienia w zależności od tego jakie operacje na bazie danych będą oni przeprowadzać. W tym wpisie zobaczymy jak zaprzęgnąć wielu użytkowników do pracy z bazą danych Wordpress'a.

Jednym z bardziej wyrafinowanych sposobów ochrony zasobów (katalogów) na serwerze www opartym o oprogramowanie Apache2 jest wykorzystanie certyfikatów klienckich. Tego typu zabezpieczenie można jednak zastosować tylko i wyłącznie w przypadku stron, które korzystają z szyfrowania SSL/TLS. Dla przykładu weźmy sobie blog WordPress'a, gdzie mamy katalog wp-admin/ i plik wp-login.php . Formularz logowania oraz panel admina zwykle są szyfrowane. Zatem każdy taki blog powinien robić już użytek z tunelu SSL/TLS w mniejszym lub większym stopniu. Jeśli teraz mamy dość niestandardową instalację WordPress'a, to przy pomocy certyfikatów możemy weryfikować użytkowników, którzy chcą uzyskać dostęp do tych w/w lokalizacji. Jest to nieco inne podejście w stosunku do tego, które zostało opisane w artykule o ukrywaniu wp-login.php oraz wp-admin, gdzie był wykorzystywany moduł mod_rewrite oraz dyrektywy Files i MatchFiles . Takie certyfikaty klienckie dają nam jednak większe pole manewru, bo identyfikują konkretnego użytkownika chcącego uzyskać dostęp do zasobów serwera. Ten wpis ma na celu pokazanie w jaki sposób zaimplementować obsługę certyfikatów klienckich w Apache2.