ugrás a tartalomhoz

Eltűnt $_POST elemek

a.d.a.m · 2011. Ápr. 11. (H), 18.58
Sziasztok,

egy számomra érthetetlen problémába ütköztem, remélem ti, nálam okosabb és tapasztaltabb forumozók a segítségemre tudtok lenni.

A gond:

Adott egy űrlap, amit postként elküldök feldolgozásra. A firebugban szépen látszanak is a szerver felé küldött adatok. Szerveroldalon egy egyszerű if függvénnyel ellenőrzöm, hogy a megfelelő tartalmú űrlapadatok érkeztek-e:
if ( isset( $_POST['_token'] ) )
Itt ért az első meglepetés, a fenti ellenőrzés minden esetben úgy futott le, mintha a _token mező értéke nem szerepelne a post adatok között (a $_POST tömbben valóban nincs benne, de a szerver felé elküldésre került).

Ha megpróbáltam a fenti ellenőrzést úgy módosítani, hogy az űrlap első sorára szűrjön (a _token mező az utolsó sor), akkor a feltétel teljesül, de amikor kiíratom az adatokat nem jeleníti meg az űrlap összes sorát, csupán egy részét (60-66 sor).

Gondoltam rá, hogy esetleg nem engedélyezett ekkora adattömeg mozgatása post-ként de a post_max_size értéke 50M. Gondoltam rá, hogy esetleg valamilyen értelmezhetetlen karakter miatt szakad meg a megjelnítés/feldolgozás, de ha csak tisztán számokkal dolgozok akkor is a fenti eredményre jutok.

Találkozott már valaki a fenti problémával, vagy van esetleg ötlet, hogy merre felé kezdjek kutakodni a megoldáshoz?

Előre is köszönöm a válaszokat.
 
1

50 mi?

solkprog · 2011. Ápr. 11. (H), 19.11
...csak mert nekem gyanús hogy (kilo)byte..
2

50M

a.d.a.m · 2011. Ápr. 11. (H), 19.38
50 mega
3

módosult

Poetro · 2011. Ápr. 11. (H), 19.42
Nem lehet, hogy valahol a kódban módosítod a $_POST tömböt? Mivel nem tudjuk, hogyan néz ki a PHP így a sorszámok nem mondanak semmit. Esetleg idézd be azt a kódrészletet, amivel reprodukálható már a probléma.
4

a kódrészlet problémás lenne

a.d.a.m · 2011. Ápr. 11. (H), 20.12
Mivel elég hosszú ezért inkább csináltam egy teszt oldalt: http://www.helyiadok.hu/test.php

Itt csak annyi történik, hogy printtel kiiratom a formot és print_r-rel a $_POST tömböt. Próbáltam egy 1000 elemes formmal (1000 input, mindben a timestamp), de ott nem volt ilyen gond, megvolt valamennyi elem tehát biztos hogy a formban hibáztam el valamit.
5

saját szerveren benne van

solkprog · 2011. Ápr. 11. (H), 20.51
nekem saját szerveren benne van a _token.
6

az elemek között

a.d.a.m · 2011. Ápr. 11. (H), 21.02
az elemek között a szla nevűnél van 2011-00785 értékű tételed is?
7

van

solkprog · 2011. Ápr. 11. (H), 21.16
[73] => 2011-00785

([szla] utolsó eleme)
8

Lehetőségek

janoszen · 2011. Ápr. 11. (H), 21.48
Tippjeim vannak rá:

  • Rewrite: a LigHTTPd-nek van egy olyan érdekessége, hogy ha rewrite-olsz egy URL-t, akkor a $_GET és a $_POST üres lesz. Megoldás a mod_magnek / LUA használata. Mivel nálad csak egy rész hiányzik, ez valószínűtlen.
  • mod_security: alapvetően a biztonság kedvéért gyártották, de avatatlan kezekben kétélű fegyver, így nem csak az elemek száma és nesting mélysége lehet problémás, hanem adott esetben az elnevezése is.
  • suhosin: két fajtában jön, a patch és a modul. Ez megint csak nézi az elnevezéseket és a nesting mélységet is. (Erre valaki találjon ki magyar szót.) A tekerentyűkről részleteket a doksiban találsz.
  • prepend fájl: webhostok előszeretettel alkalmazzák, simán lehet, hogy a hostod kiszűrt valami paramétert, mert egyébként egy exploithoz tartozik.
  • proxy: sikerült pont belefutni, hogy az nginx default beállításokon meglehetősen hisztis a bemenő paraméterekre és a post méretére. Azért nem valószínű, mert erre egyértelmű HTTP hibát kapnál.
  • rossz karakter: Ha valahogyan sikerül a requestbe egy nul karaktert varázsolni, akkor a fentiek bármelyike elég erősen hisztizhet érte, az ugyanis hack-gyanús.


Kérdéseim:

  • Milyen webszerver? Milyen modulok? Van-e proxy?
  • Van-e valahol .htaccess? (Ha Apache persze.)
  • Küldj egy phpinfo() kimenetet légyszi.
10

a válaszok

a.d.a.m · 2011. Ápr. 11. (H), 22.37
A phpinfo:
http://helyiadok.hu/info.php

htaccess állomány van:
- Rewrite modul aktív (rövid címek)
- valamint egy árva php beállítás (jelentősége immár nincs, alapbeállítás lett): php_value display_errors 0

Átfutottam az ötleteidet, nekem első körben a rossz karakter opció a gyanús
12

ha nem rejtett

a.d.a.m · 2011. Ápr. 12. (K), 13.58
Új fejlemény, ha az inputok type-ját hidden-ről text-re változtatom, akkor valamennyi postolt érték megjelenik a print_r()-rel történő kiíratáskor.
13

Fura

janoszen · 2011. Ápr. 12. (K), 14.08
Próbáld meg Wiresharkkal kidumpolni a két requestet és hexeditorban összenézni. (Btw. nálunk minden gépen telepítve van és rendszeresen használják is a fejlesztők.)
9

cache

carstepPCE · 2011. Ápr. 11. (H), 21.56
Esetleg próbáld meg kiüríteni a böngésző cachet. Néha be tud ragadni form érték. Főleg chrome alatt jellemző.

Üdv
Sanyi
11

másik gép másik böngésző

a.d.a.m · 2011. Ápr. 11. (H), 22.38
Próbáltam másik gépről, másik böngészővel, sajnos nem javult a helyzet.
14

A megoldás

a.d.a.m · 2011. Ápr. 12. (K), 15.42
Idézem a szolgáltató válaszát:

A webserveren működő suhosin patch okozta a gondot. A postban résztvevő változók száma volt korlátozva.


A pont (ha lenne) proclub-ot illeti. Köszönöm a segítséget.