egy elég érdekes jelenséggel találtam szembe magam.
adott egy 6.14 drupal több tucat telepített modullal (itt megnézhető a kivonat), ezek között azonban nincs semmilyen access control jellegű.
uid=1 userrel vagyok belépve. úgy néz ki mindenhol minden jól működik, de most bele akartam nyúlni a navigációba (letiltani egy menüpontot) és az a meglepetés ért, h POST után egy nagy "Hozzáférés megtagadva" üzenet fogad + ki is léptet az aktív session-ből.
az plusz érdekesség az, hogy ha mondjuk az elsődleges linkeket szerkesztem akkor ott gond nélkül megy minden.
találkozott már valaki ilyennel illetve van valami ötletetek h merre tovább?
debug folyamatosan megy. az már tuti, h nem a böngésző kéréssel van a baj, mármint h jó session azonosítóval megy a kérés.
A Drupal és a többi logba
A Drupal és a többi logba nincs valami esetleg?
Hosszu Kálmán
http://twitter.com/kalmanhosszu
http://www.kalman-hosszu.com/
http://premiumcmsthemes.com/
elfelejtettem írni
de nyilván ezek voltak az elsők amiket megnéztem.
szerver log tiszta.
drupal logokban is csak annyi látszik, h anonymous akarná megnézni az oldalt (admin/build/menu-customize/navigation) és h ezért access_denied.
más sehol semmi.
úgy néz ki, h más is találkozott már a jelenséggel...
extra érdekesség
az, hogy ha vmi hozzáférésszabályozási probléma/bug lenne, akkor sima access_denied üzenetet kapnék, de nem dobna ki a session-ból és generálna új session azonosítót (set-cookie)
szerk.:
ja és a kiléptetés valamikor a http post után történik, mert ha ellátogatok a navigáció szerkesztő oldalra, de ott nem módosítok semmit akkor tovább tudok menni máshova.
misztikus...
Ha sok a modulod, akkor
próbáld megnövelni a php.ini-ben:
Páldi Zoltán
nincs hiba a szerver logban
tehát max_execution_time átlápés sincs.
amúgy saját magam által karbantarott környezetről van szó, eleve megemelt paraméterekkel. többek között:
memory_limit=128M
max_execution_time=120
max_execution_time hiba egyébként már csak azért sem lehet, mert a post után (gomb megnyomása) rögtön megy a redirect és a hozzáférés megtagadva oldal, tehát nem kell várni rá...
azért köszi! :)
update
nos, a dolog kezd érdekes fordulatot venni... úgy néz ki nem feltétlenül drupal specifikus a probléma.
miután minden nem core modult lekapcsoltam továbbra is fennállt a hiba. ezek után csináltam egy szűz installt, az eredmény ua.
észrevettem, h a fejlesztői gépemen (laptop) viszont nincs ez a jelenség csak a szervereimen, szóval elkezdtem tovább göngyölni a szálakat.
a különbség a laptop és a szerverek között (mindkettő linux/apache2.2/php5.2) az, h fejlesztésnél sima mod-php5 van használva míg éles környezetben cgi módban futtatom a php-t...
egy teszt idejére visszaállítottam mod-php -ra az említett oldalt, a hiba ez esetben nem jelentkezik.
gond lehetne a különböző php konfigokban (cgi-ként más más konfigott használ virtualhostonként), de ez ellenőrizve és kizárva mint hibaforrás.
tehát:
úgy néz ki, h cgi módban valamiért annál az egy(!) admin szekcióban (talán ott van csak olyan sok elem a postban) a post során valahogy a drupalig nem jut el minden aminek kellene (pl session id) így kivág a rendszer és jön az access denied.
kicsit nehezebb lesz ezt tovább debuggolni, de remélhetőleg megoldom :)
íme a megoldás
elég aljas volt, de megvan :)
szóval itt van, hátha valaki találkozik még evvel a jelenséggel.
ha suhosin hardened php működik a szerveren, akkor a suhosinnnak van (többek között) egy default limitációja (még ha semmilyen suhosin beállítás sincs a konfigban), miszerint a POST-ban átadva max 200 változót engedélyez deklarálni.
sok modul esetén a navigációhoz tartozó menüpontok száma elég nagy és ennek a menünek az adminisztrálásakkor 200nál több elemet küld el (egy rakás checkbox, súly) a böngésző azonban a suhosin default beállítás miatt a drupal-hoz csak az első 200 jut el.
ebből következik a hiba.
az érintett php.ini-ben az alábbi deklarációval küszöbölhető ki a probléma:
suhosin.post.max_vars = x
esetleg kellhet még a
suhosin.get.max_vars = x
suhosin.request.max_vars = x