Od razu zaznaczam, że to co piszę nie ma żadnego potwierdzenia i są to jedynie domysły poparte doświadczeniem zawodowym.
No więc tak. Na początek ustalę kilka faktów:
- aplikacja sklepu Steam działa na PHP
- sklep używa Apache Solr - to tylko ciekawostka, nie ma znaczenia
- sklep używa memcache - nie jest to nic dziwnego, każda szanująca się aplikacja webowa, która może używać cache powinna to robić czy to za pomocą memcache czy redis czy cokolwiek innego
- za obsługę CDNa i ochrony anty-DDOS odpowiada Akamai - jest to firma nie związana z Valve w jakikolwiek sposób, jak ktoś kojarzy to Akamai zajmuje się tym samym co Cloudflare, generalnie ciekawostka
, ale ma znaczenie o którym napiszę w dalszej części posta
Jakiś czas przed tym jak się zaczęły dziać cuda na sklepie można było zauważyć, że z jakiegoś nieznanego powodu jeden z wielu tzw. serwerów webowych zaczął serwować stronę sklepu z debugiem. Pisałem o tym dzisiaj ja i inni w tym topicu. Rzuciłem również copy-paste debuga z jednej strony. Z tego debuga można było wyciągnąć kilka ścieżek do plików .php aplikacji sklepu (co nie znaczy, że były one dostępne do pobrania - pewnie nie) oraz adresy IP (wewnętrzne, nie publiczne) serwerów memcache. Poklikałem po tym pseudo paneliku i w sumie nic ciekawego poza logiem debuga tam nie było.
Jakiś czas później na stronie sklepu zaczęły się zmieniać języki i można było podejrzeć kogoś konto. Żeby wytłumaczyć ten fenomen trzeba zrozumieć czym jest sesja i w jaki sposób się nią operuje. Generalnie fakt tego, że jesteśmy zalogowani, to że sklep "pamięta" co mamy np. w koszyku itp. rzeczy są utrzymywane przez sesje. Sposób obsługi sesji jest dowolny - jak sobie programista wymyśli, ale na Steamie pewnie działa to mniej więcej tak: w momencie jak wchodzimy na stronę serwer generuje nam unikalny klucz sesji, który jest zapisywany po stronie serwera, a sam klucz jest zapisywany w naszej przeglądarce w pliku cookie. Klucze sesji powinny być zawsze unikalne, ale załóżmy, że z jakiegoś powodu nie są. Przykładowa sytuacja: Osoba A loguje się do sklepu, dostaje klucz 123, jakiś czas później kolejna (inna) osoba B wchodząc na stronę musi mieć wygenerowany nowy klucz, ale z jakiegoś powodu nowo wygenerowany "losowy" ciąg znaków jest taki sam jak już istniejący (np. 123). Skutkuje to tym, że osoba B widzi to co osoba A, ale w takim przypadku mając jej sesję może praktycznie robić wszystko (kupować, pisać jako ta osoba itd.) W tym przypadku, który zaistniał tak nie było, mieliśmy tylko "odczyt" danych, ale kliknięcie czegokolwiek dawało albo błąd albo nic się nie działo. To z kolei sugeruje pewien zabieg, który być może wykonuje Valve na sklepie Steama, ale to jest tylko moja teoria i nie twierdzę, że tak jest na bank. Otóż przypuszczam, że Valve cachuje content dynamiczny, żeby ograniczyć zapytania do bazy danych, co potwierdza debug z wcześniej dzisiejszego dnia. Z jakiegoś powodu cache z sesji innych osób był dostępny dla wszystkich użytkowników. Niestety nie jestem w stanie powiedzieć dlaczego tak się stało ponieważ nie wiem jak operują memcache'm. Być może z jakiegoś powodu klucze w memcache zaczęły się nakładać. Ale bardziej obstawiałbym, że winna jest ta "beta/debug" aplikacja, która pojawiła się przez pewien czas na store. Obstawiam, że aplikacja debugowa zrobiła jakieś lewe wpisy do memcache przez co właściwa aplikacja (produkcyjna) zaczęła serwować złe dane z cache. Być może przestały się zwalniać zasoby cache - nie wiem.
Nie chcę wychodzić na alfę i omegę, więc ponownie nadmieniam - to są tylko moje domysły. Być może można je obalić w całości jednym zdaniem.
W międzyczasie jak pisałem tego posta SteamDB napisali swojego -
https://steamdb.info/blog/recent-cachin ... -on-steam/ który poniekąd stwierdza to samo co mój.