Upload souboru z Flashe + ověření uživatele
- jirik
- Člen | 2
Řeším teď upload souboru z Flashe (YUI Uploader, SWFUpload) přihlášeným uživatelem (Nette/User), tzn. na server se musí dostat cookies.
První problém je v tom, že Flash Player
v prohlížečích jiných než IE neposílá cookies (podle http://developer.yahoo.com/yui/uploader/#…), případně
posílá cookies z IE, ne z prohlížeče, ve kterém běží (podle http://swfupload.org/…scussion/383).
To lze vyřešit tak, že společně se souborem se ty cookies pošlou v POSTu,
YUI Uploader i SWFUpload to bez problémů umí. S Nette je to trochu
složitější (a bezpečnější), protože PHPSESSID i „nette-authkey“
jsou httponly cookies, takže nejsou z javascriptu dostupné. „Řešením“
je poslat si je ze serveru v HTML kódu stránky.
V PHP skriptu, který řeší ten upload souborů, je pak potřeba ty hodnoty zase z $_POST nastavit do $_COOKIES a do session_id() a pak ověřit přihlášení uživatele ( user->isAuthenticated() )
A zde nastává druhý problém, který už nevím, jak
vyřešit. Prostě uživatel stejně přihlášený není a vygeneruje se nové
session_id.
Podle toho, co jsem se dočetl na fóru (https://forum.nette.org/…iewtopic.php?…)
má Nette ochranu proti ukradení session (podle některých HTTP hlaviček).
Předpokládám, že je to porovnává s předchozím požadavkem. Pokud ne,
rád se dovím, jak to funguje.
Pokud ano, tak je asi skoro jisté, že hlavičky budou jiné při požadavku
z prohlížeče oproti požadavku z Flash Playeru, takže Nette to vidí jako
ukradenou session, takže vygeneruje nové session_id a uživatele to
neověří. Přesně takhle se mi to chová, uživatel není přihlášený a je
nové session_id.
Takže se chci zeptat, jestli ta ochrana proti ukradení session (resp. rozdíl v HTTP hlavičkách) může být příčinou, případně jestli tu ochranu lze ve skriptu nějak programově vypnout.
Díky za radu.
- pmg
- Člen | 372
Myslím, že o druhém problému píšou někde dole v dokumentaci.
K odesílanému souboru je možné připojit ještě další data, čehož
můžeš využít pro předání nějakého klíče. Asi bude nejlepší udělat
speciální UploadPresenter, který nebude kontrolovat
přihlášení uživatele. Zbytek formuláře se pak odešle normální
cestou.
- David Grudl
- Nette Core | 8228
Pokud je problém v tom ověřování HTTP hlaviček (jde o
Accept-Charset, Accept-Encoding, Accept-Language, User-Agent), tak
to lze vypnout
pomocí Environment::getSession()->verificationKeyGenerator = FALSE
Nicméně je to potřeba vypnout globálně, to znamená pro každý request. Přemýšlím, jestli kód neupravit tak, aby se to dalo vypnout jen pro jeden konkrétní request.
- washo
- Člen | 88
jirik napsal(a):
Rozumím co oba myslíte. Prostě neověřovat uživatele (session), ale nějaký kód.
Díky.
Co za kod byste zvolili?
Myslim ze by uverovani melo fungovat podobne jako ochrana proti CSRF, ale
k tomu potrebuju prave tu session ne?
//Pokud se to tu jiz resilo omlouvam se. Nemuzu to tu na foru najit
- pekelnik
- Člen | 462
Toto řešení má dvě nevýhody:
- vypnout kontrolu user-agenta není dobrý nápad ani na tak „malicherné“ akci jako je upload souboru :)
- posílat session id v kódu stránky není dobrý nápad vůbec
Navíc se obávám, že vypnutí kontroly user agenta nebude stačit. Problém je v tom, že při volání funkce session_id() se vždy odešle nová cookie bez ohledu na to co tam nastavíte. Viz dokumentace session_id(). Prohlížeč tedy při dalším požadavku je poněkud mimo mísu, protože požadavek od flashe mu zničil session – nová cookie samozřejmě dorazí do flashe a ne do prohlížeče.
Čistým řešením je vytvoření ticketů pro upload a ty oveřovat proti něčemu jinému než je problematická session, např. proti databázi.
- PetrP
- Člen | 587
pekelnik napsal(a):
- vypnout kontrolu user-agenta není dobrý nápad ani na tak „malicherné“ akci jako je upload souboru :)
Kontrola user agenta stejně není kdovíjaké zabezpečení, jeho podvrhnutí i získání je triviální.
Jinak ale s ostatním souhlasím. Vytvoření jednorázového tiketu jen na tuto akci je asi nejlepší.
- romansklenar
- Člen | 655
Pokud se vám to podařilo nějak systémově vyřešit, tak by z toho byla určitě pěkná a poptávaná komponenta do extras.