ako na príkaz delete v <a href="">

Takeshi

Ahojte,
mám nasledovné

<a href='{link delete! $articleId}' onClick="confirm('Naozaj chcete tento článok vymazať?')">link</a>

public function handleDelete($id)
{
    ... delete clanku ...
}

všetko by bolo v pohode, ale ked dam pri kontrolnej otazke, ci chcem naozaj vymazať článok, tak mi tú akciu delete článku urobí či dám OK alebo ZRUŠIŤ

ako sa to správne robí?

David Matějka

nesouvisi s nette, ale poradim.. chybi ti tam return pred confirm(..

Takeshi

OK, v tom pripade sa ospravedlnujem … a dakujem

Michal Vyšinský

Já často používám něco takového:

<a href="{link delete! $articleId}" data-confirm="Opravdu?">Smazat</a>

$(function(){
  $('[data-confirm]').click(function(e){
    e.preventDefault();
    if(confirm($(this).data('confirm'))) {
       location.href = $(this).attr('href');
    }
  });
});

Jen místo škaredého confirm používám většinou modal okna.

Editoval Michal Vyšinský (23. 9. 2014 11:50)

japlavaren

btw, odkazy by nemali sluzit na mazanie, pouzi form

David Matějka

@japlavaren j neni to idealni.. ale melo by stacit secured-links :)

Šaman

japlavaren napsal(a):

btw, odkazy by nemali sluzit na mazanie, pouzi form

Nechápu. Proč?

Editoval Šaman (23. 9. 2014 20:44)

japlavaren

ak ti niekto podstrci odkaz a kliknes ho (i ked malo pravdepodobne)
ak sa ti robot dostane do administracie a navstivi vsetky odkazy, je to v k****e

Editoval japlavaren (23. 9. 2014 20:55)

David Matějka

@japlavaren

https://forum.nette.org/…ete-v-a-href#…
jestli se ti dostal robot do administrace, tak mas vetsi problem jinde :)

japlavaren

ja som stara skola. odkaz je odkaz a pre akciu je form…

Šaman

IMHO formulář je od toho, aby se jím něco zadávalo. Formulář, který nemá žádné inputy, není formulář.

Casper

@Šaman Ono to především není o tom jestli formulář či odkaz, ale o použité HTTP metodě. Tím, že použiješ GET metodu pro nějakou akci, tak porušuješ její základní safe vlastnost (a pravděpodobně i idempotenci). A to se všemi důsledky co z toho plynou. Tedy například otevíráš vrátka pro zmíněný CSRF útok. Dalším problémem může být cachování. Například proxy server, který si cachuje GET požadavky se při snaze obnovit svou cache ti znovu zavolá tvou akci. Zkrátka a jednoduše, dle specifikace HTTP slouží na akce především POST metoda.

Jenže je trochu opruz na každou blbost psát formulář s jedním submit buttonem a k tomu ještě továrničku, takže všichni používají signály, které často porušují specifikaci HTTP :) Osobně bych už bez secured-links doplňku vůbec signály nepoužíval.

thm

Mohu se zeptat jak secured-links funguje? Co to přesně udělá?

Zax

Hackuje metody link() a signalReceived(). Pokud tomu dobře rozumím, tak ke každému vytvořenému odkazu, který směruje na signál s anotací @secured, se vytvoří náhodný token, který se uloží do session a hash toho tokenu se připojí do odkazu jako parametr _sec. Při přechodu na zabezpečený signál se pak kontroluje, jestli ten hash sedí s tím, co je v session (= kliklo se na zabezpečený odkaz), a pokud ne (podstrčený odkaz, parametr _sec chybí nebo nesedí), vyhodí se výjimka a ke zpracování signálu nedojde.

kolsi

Narazil jsem na toto trochu starší téma, ale řeším podobný problém, tak se zeptám, zda to secured-links by pomohlo ho vyřešit.

V naší aplikace jsme narazili na docela závažný bezpečnostní bug, který spočívá v tom, že signál není vázaný na konkrétní action. Když uživatel chce provést nějakou akci, tak v action ověříme, zda má oprávnění k této akci a podle toho ho pustíme dál, nebo vyhodíme chybu.

Teď situace, když mám seznam (třeba Grido), kde mazání položek probíhá AJAXem (tedy signál). V actionList se ověří oprávnění, handleDelete pak položku smaže. Nad tlačítkem Delete je pak odkaz …/project/list/55?do=delete a všechno ok.

Teď někdo zadá URL …/project/abcdef/55?do=delete a co se stane? Jelikož actionAbcdef neexistuje, tak se ani nikde neověří oprávnění. Následně se zavolá actionDelete a položka se smaže.

Vyřeší to secured-links? Nebo se jedná o špatný návrh? Nebo je prostě potřeba v handleru ověřit oprávnění ještě jednou? Či jak jinak to řešit?

looky

@kolsi Určitě bych ověřoval práva všude tam, kde dělám něco na co by někdo nemusel mít právo..

Editoval looky (5. 3. 2015 10:49)

kolsi

Ještě mě napadlo, jestli by to nešlo pořešit nějak obecněji – např. zavést pro handlery anotaci, která řekne, že ten handler může být volán pouze pro vyjmenované akce. Celkově by to pak vyřešilo problém, že někdo podstrčí signál do špatné akce.

Etch

@kolsi Tak se to v praxi často dělá, že si člověk vytvoří anotaci s whitelistem akcí, na kterých může být daný signál zavolán. Osobně pak existenci této anotace vynucuji, takže nelze provést signál bez této anotace.

Je to tak jak píše @looky. Vždy záleží na tom, jak se na to koukáš. Já většinou ověřuji oprávnění až na úrovni modelu, takže to že jde signál pustit na jiné akci by mě nemuselo příliš zajímat, protože daná operace stejně selže. Přesto whitelist akcí pro signál v anotaci dělám, abych měl dobrý pocit. :)

kolsi

Tak my máme oprávnění na globální úrovni v BasePresenteru, kdy ve startupu se volá funkce checkPermission (každý presenter už implementuje sám), která ověří přístup podle kombinace presenter/action/id a podle toho uživatele na danou stránku (ne)pustí. Ty signály jsme nějak přehlídli, protože to neprošlo přes action, ale už nám nedošlo, že tu action tam můžu podstrčit jakoukoli (čili tu na kterou mám oprávnění) a handler se stejně zavolá.

V Nette ty anotace/whitelisty asi nebudou co? Existuje na to nějaký už hotový doplněk, nebo musíme implementovat sami (což asi nebude problém)?