Jako że web developer goni za nowościami, przyszedł czas na upgrade serwerów testowych (przed wdrożeniem na produkcję). Czy zwykła zmiana wersji mogła odbyć się bez problemów ? Oczywiście że nie. To akurat wie każdy.
Korzystamy dla przechowywania sesji Memcached. Po pierwsze w miarę szybkie i ładnie działa, po drugie sesja jest wsþółdzielona pomiędzy sporo serwerów. Oczywiście logowanie przez SSL’a przestało działać.
Więc w pierwszej kolejności pretensje poszły do naszej aplikacji „Znowu coś zjebaliście !”, później memcache i na koniec serwer. A nie winne były ustawienia PHP. Jeśli posiadacie serwer oparty na Debianie lub jego potomków, sprawdźcie czy macie zainstalowane rozszerzenie Suhosin, a jeśli tak to czy poniższe zmienne macie tak ustawione.
suhosin.session.encrypt = off suhosin.session.cryptua = off
To magiczne rozszerzenie ma skłonności to innego sposobu zapisywania danych w naszej sesji. Jest to string base64 po rozkodwaniu którego znajdujemy jakiś bliżej nie określony zapis binarny. Którego nie mamy jak rozkodować. Sytuacja jest o tyle dziwna, że ta sama domena z SSL’em i bez są traktowane jak by były osobno ale nie. Sesje pomiędzy tak parą domen są osobne. Każda zapisuje się oddzielnie, pod tym samym session_id. Oczywiście parametry sesji są ustawione tak żeby domeny wspólnie korzystały z sesji. Niestety nie udało mi się rozkodować tego co sesja zapisuje. Może jeszcze znajdę chwile to postaram się zrozumieć to zjawisko. W każdym bądź razie. Rozszerzenie wyłączyć lub zmienić ustawienia i problemy znikają.
Minuta szukania na google: http://www.hardened-php.net/suhosin/configuration.html#transparent_encryption_options
Konfigurujesz Suhosin jak należy i nie musisz wyłączać zabezpieczenia szyfrowaniem.
Podpowiem:
cryptkey – identyczny na serwerach
cryptdocroot – ustaw na 0 jeśli docroot na różnych serwerach jest różny
I voila.