Autor wpisu: zleek, dodany: 30.12.2011 10:59, tagi: php, zend_framework, css
Autor wpisu: zleek, dodany: 26.12.2011 22:35, tagi: php, zend_framework, mysql
Autor wpisu: zleek, dodany: 25.12.2011 21:16, tagi: php, zend_framework
Autor wpisu: zleek, dodany: 25.12.2011 00:00, tagi: php, zend_framework, mysql
Autor wpisu: zleek, dodany: 24.12.2011 17:19, tagi: php, apache
Autor wpisu: Tomasz Sh4dow Budzyński, dodany: 16.12.2011 15:30, tagi: php
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ą.