pohadkar
commented
6 years ago pokud je formular ve view sablone, je je jeden na strance a odesila se POSTem, je vse v poradku. problem nastava v techto pripadech.
- formular je sice v sablone, ale odesila se post ajaxem, bez reloadu stranky. z funkce csrf je zrejme, ze pokud je na ajaxove ceste pouzite csrf middleware, budou po jeho prvnim odeslani overovaci inputy neplatne. dalsi vec, ktera s timto souvisi je to, ze se musi do ajaxu tyhle klicove promenne dat taky, jinak se ajax request vrati s kodem 400, bad request.
da se resit bud tak, ze se na tyto ajaxove requesty csrf middleware nepouziva, nebo ze se pouzije tzv. persistent klic. ten ale v nasi verzi csrf jeste neni. museli bychom zvednout verzi. vetsinu ajaxu navic mame delanych tak, ze slouzi jen jako dotazy na vypis neceho. a neslouzi jako formulare. takze zatim to resime tak, ze na ajaxy csrf nepouzivame.
- formular je vracen ajaxem jako obsah stranky.
jde napriklad o pripad browseru storu, kdy se objevi formular pro upload souboru pouze v pripade, ze jsme v nejakem objektu v nejake app.
tento formular se pak normalne odesila postem. ale do stranky se dostane dynamicky az pote co bylo generovani csrf pouzito na samotnou stranku.
mame opet nekolik moznosti.
- cesta pro ajax nebude mit middleware csrf, tj se nevygeneruje nove a do formulare se prekopiruje uz vygenerovane csrf, ktere je nekde na strance. (snizena bezpecnost)
- cesta pro ajax nebude mit csrf, ani ten vygenerovany formular nebude mit csrf (vubec zadna bezpecnost)
- cesta pro ajax bude mit csrf. to ale znamena nekolik problemu. jak dostat nove vygenerovane klice do formulare. jak zajistit aby se samotne volani ajaxu neoverovalo s predchozim csrf. nove vygenerovane klice do formulare dostaneme tak, ze formular bude v partial sablone, kterou na vystupu ajaxu vyrenderujeme a klice se do ni dosadi standardnim slim zpusobem samy. samotne volani ajaxu od csrf oprostime tak, ze ajax zavolame GET metodou. pokud bychom mermomoci museli ajax volat POST metodou, musime si na strance ulozit predchozi vygenerovane csrf klice a ty pak pridat do posilanych ajax promennych. zde by opet mohlo v budoucnu pomoct persistent vygenerovani klicu. ale aktualne je to riziko, protoze nevime jak to presne funguje.
jak funguje CSRF middleware:
pouziti middleware sestava ze dvou casti. ->add(new \Glued\Middleware\Forms\CsrfViewMiddleware($container))->add($container->csrf)
prvni cast: add(new \Glued\Middleware\Forms\CsrfViewMiddleware($container)) pridava globalni promennou csrf.field jejiz obsah naplni dvema inputy s predgenerovanymi overovacimi klici. pokud je pak vysledek renderovan pomoci view a v sablone se nachazi {{ csrf.field | raw }}, je tento v procesu renderu nahrazen tou globalni promennou.
druha cast: (protoze se middleware zpracovavaji systemem lifo, provede se pred prvni casti) add($container->csrf) funguje takto: pro kazdy dotaz typu 'POST', 'PUT', 'DELETE', 'PATCH' provede overeni, jestli jsou pritomny overovaci klice a porovna je s posledne vygenerovanymi, ktere ma v session. pri neexistenci nebo nesouladu vraci ruzne chyby :) dale vygeneruje nove overovaci klice a ulozi si je do session, at je typ dotazu jakykoliv (napriklad i GET).
znamena to, ze pri kazdem requestu jsou vygenerovany nove klice a plati pouze na zacatku dalsiho requestu.