Tag: bug

Opublikowane w

MacOS 14.2 – nie działa hidutil

Ja jeszcze nie zaktualizowałem MacOS do wersji Sonoma, ale znajomi zdążyli to zrobić i narzekają, że polecenie hidutil przestało działać. Nie zwraca błędu, ale nie mapuje klawiszy. W związku z tym polecane kiedyś przeze mnie mapowanie klawiszy bez użycia Karabiner Elements również nie będzie działać.

Sprawdzonego rozwiązania w tej chwili nie podam, zamiast tego odsyłam do wątku na forum Apple oraz wątku na Reddicie. Jest tam wiele pomysłów na rozwiązanie, można przymierzyć – może ktoś znajdzie satysfakcjonujące dla siebie.

Ludzie zgłaszają błąd do Apple, więc liczę, że błąd zostanie poprawiony w kolejnej aktualizacji. Mapowanie bez dodatkowych programów było eleganckie.

Opublikowane w

WordPress i kłopoty z cache – rozwiązanie

Od pewnego czasu na blogu występuje problem. Objawia się on tym, że niektóre wpisy nie wyświetlają się w całości, są jakby obcięte. Zauważyłem to parę dni temu, ale wtedy uznałem za jednorazowy wybryk i machnąłem ręką. Po części zwaliłem sprawę na cache, bo jego wyczyszczenie pomogło. Po głowie jako przyczyna chodziło mi też coś w stylu DDoS, który po publikacji artykułu na blogu uprawiają serwery Mastodon. I zupełnie nie miałem czasu na analizę.

Jednak dotarły do mnie sygnały (dzięki!) o tym, że sprawa się powtarza, postanowiłem przyjrzeć się bliżej. Dziś wszedłem z telefonu na ten sam wpis i… problem wystąpił ponownie. Z racji pory dnia ruch powinien być niewielki, więc warunki do diagnostyki powinny sprzyjać.

Trzy słowa o setupie

Blog jest dumnie wspierany przez WordPress, wykorzystywany jest nginx oraz php-fpm 8.2. Do tego dość intensywnie korzystam z wtyczek do WordPress. W szczególności do różnych optymalizacji i cache, co raczej nie ułatwi diagnostyki. Dużo elementów ruchomych, ingerencja w treść serwowanej występuje w wielu miejscach.

Wspomniałem o pluginie do cache jako jednym z podejrzanych. Konfiguracja Cache Enabler wygląda następująco:

Konfiguracja Cache Enabler
Screenshot konfiguracii Cache Enabler

Objawy i logi

Obcięty wpis wygląda tak:

Ucięty wpis na blogu
Screenshot uciętego wpisu

Cache był wygenerowany o 07:48 i pokrywa się to z czasem wejścia z telefonu widocznym w access.log.

drwxr-xr-x 2 www-data www-data 4096 Sep 24 07:48 pentagram-cerberus-p6361-rzut-okiem-na-bezpieczenstwo

W logu php-fpm nic specjalnego. Chwilę wcześniej widać raczej nie mogące mieć wpływu

[24-Sep-2023 07:44:23] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 1 idle, and 10 total children
[24-Sep-2023 07:44:27] WARNING: [pool www] child 20688 exited on signal 9 (SIGKILL) after 33847.200506 seconds from start
[24-Sep-2023 07:44:27] NOTICE: [pool www] child 25769 started

Diagnostyka

Problem występował na różnych przeglądarkach, także w trybie prywatnym. Zarówno na desktopie, jak i mobile. Sprawdzenie wersji zapisanej w cache pokazało, że jest ona błędna. Dobry znak, bo raczej można wykluczyć wpływ JSów. Były one podejrzane, bo wprawne oko dostrzeże, że polecenie curl przechodzi w pewnym momencie w kod źródłowy strony związany ze skryptem od statystyk Matomo.

Udało mi się ustalić, że wyczyszczenie cache pomaga, ale… tylko na pierwsze wyświetlenie. Kolejne wyświetlenia są już błędne. Sam problem występował niezależnie od obsługi JS. Czy to Firefox, czy links2, czy lynx – pierwsze wyświetlenie było poprawne, kolejne błędne.

Na pierwszy ogień poszły więc ustawienia wtyczki robiącej cache. W Minify HTML in cached pages including inline CSS and JavaScript wyłączyłem miniaturyzację CSS i JS. Nie pomogło.

Natomiast zupełne wyłączenie tej opcji jak najbardziej pomogło. Winnym okazała się zatem jedna z opcji wtyczki Cache Enabler w wersji 1.8.13. Takie tam ryzyka optymalizacji. Zgłosiłem problem na GitHub i zobaczymy co będzie dalej.

Rzuciłem jeszcze okiem na przyczynę. Prawdopodobnie chodzi o niepoprawne, zachłanne parsowanie komentarzy. Obcięcie następuje po pierwszym znaku *.
Gecko/20100101 Firefox/60.0' -H $'Accept: */*' -H $'Accept-Language: en-US,en;q=0.5'
natomiast linia bezpośrednio przed tym, co się zaczyna pojawiać, wygląda tak:
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */

Opublikowane w

Google, he knows me

Dostałem maila od Google. Na stronie wykryto błędy, kod błędu 403. Sprawa mnie zaintrygowała. Co prawda chodziło tylko o jeden URL, ale czemu 403? Błędy 5xx czy 404 bym zrozumiał jeszcze, zwłaszcza na blogu, ale 403? Coś się tu zdecydowanie nie zgadza.

Rozpocząłem dochodzenie i zrobiło się dziwniej. Bowiem chodziło o zupełnie egzotyczny URL ( hxxps://zakr.es/tststs/ ). Na oko poprawny, ale ewidentnie tymczasowy i testowy. I zdecydowanie nie należący do bloga. W ogóle byłem zdziwiony, że Google o nim wie.

And he knows I’m right

Pierwsze co przyszło mi do głowy to robots.txt. Może dlatego, że sugerują sprawdzenie, czy dostęp nie jest tam blokowany? W każdym razie pudło. Zresztą nawet gdyby tam URL był, to raczej jako wykluczenie dla botów. A wtedy zgłaszanie braku dostępu byłoby sporą bezczelnością.

Zajrzałem do katalogu na serwerze i przypomniało mi się, że testowałem pewną rzecz. Powiedzmy, że okolice bug bounty. Tak, robienie tego na podstawowej domenie to zwykle kiepski pomysł, ale tym razem kluczowa miała być obecność naturalnego ruchu. Tak czy inaczej nic z tego nie wyszło, tj. nie udało mi się wykorzystać w planowany sposób. A katalog pozostał, choć już niewykorzystany. I nielinkowany.

Analiza

Google webmaster tools[1] pokazuje, skąd jest linkowana dana strona. W tym przypadku podał dwie strony na blogu. Jedną z konkretnym wpisem, drugą zbiorczą.

Strona odsyłająca
https://zakr.es/blog/author/rozie/page/6/
https://zakr.es/blog/2015/10/spis-wyborcow-a-rejestr-wyborcow/

Tyle, że w podglądzie źródła tego ostatniego wpisu to ja tego URLa w żaden sposób nie widzę.

Jak to wygląda czasowo? Kolejna ciekawostka to kolejne dwie daty w Google webmaster tools:

Data pierwszego wykrycia: 31.08.2022

Zapewne wtedy się bawiłem. Daty utworzenia plików potwierdzają – wszystkie pliki mają 03.08.2022. Ma to jakiś sens, tylko musiałbym zostawić pliki podlinkowane na miesiąc? Raczej niemożliwe, bo wtedy zostałyby na stałe. A nie ma. No i skąd by się wzięły w tak starym wpisie?

Ostatnie skanowanie 5 maj 2023, 11:47:16

To oczywiście możliwe, tym bardziej, że Google zauważyło błąd 403 dokładnie 3 maja 2023. Po ponad pół roku?

I’ve been talking to Google all my life

Jeśli chodzi o Google, to mamy love hate relationship. Z jednej strony doceniam firmę za GCTF, czy zabezpieczenia poczty i kont. Z drugiej strony to, co robią z prywatnością userów, nachalność reklam, tragiczny, scamerski content części reklam bąbelkowanie w wyszukiwarce i wreszcie samo bycie globalną korporacją mocno mnie odstręczają.

Ostatecznie jest tak, że umiarkowanie korzystam z ich usług. Trochę, bo wygodne, trochę, bo wypada znać. Mam webmaster tools, mam reklamy AdSense, ale tylko w wybranych miejscach. Pozwalam indeksować blog. Raczej nie korzystam z ich wyszukiwarki, tj. sięgam do niej tylko, jeśli nie znajdę wyników w podstawowej, czyli rzadko. Inne usługi Google, czyli np. Maps, Waze, translate, calendar, drive, docs – różnie, raczej korzystam, choć w ograniczonym stopniu.

Częściowe wyjaśnienie

Spojrzenie w logi serwera mówi nieco więcej:

66.249.65.223 - - [28/Aug/2022:20:35:53 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.79 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.70.63 - - [30/Aug/2022:20:53:52 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.5112.79 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.227 - - [30/Apr/2023:22:32:01 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.231 - - [03/May/2023:10:44:18 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.64.229 - - [05/May/2023:11:47:16 +0200] "GET /tststs/ HTTP/1.1" 403 187 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.5615.142 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Część rzeczy się zgadza, np. wizyty kiedy Google zauważyło i zaindeksowało URL, po miesiącu od zamieszczenia plików. Widać też wizyty 03.05, kiedy sobie o nim ni stąd ni zowąd przypomniało. Mogło się też zdarzyć, że do testów wziąłem jakiś stary wpis z 2015.

Nadal nie zgadza się – albo nie mogę sobie przypomnieć – jak to się stało, że URL został na miesiąc, a nie został na stałe. I słodką tajemnicą Google pozostanie, czemu zapomniało o tym URLu na bite osiem miesięcy.

Usunąłem katalog z serwera. Może teraz Google, gdy dostanie 404, zapomni o nim na dobre?

[1] Obecnie Google Search Console, ale przywykłem do starej nazwy, więc przy niej zostanę, przynajmniej w tym wpisie.