[Løst] Javascript confirm på lenker

[Cerandin]

Hei!

 

Jeg prøver å få til en confirm boks når noen trykker på lenken slett. Jeg aner ikke hvordan jeg skal få javascripten til å fungere på lenken, jeg har prøvd et og annet uten hell.

 

her er koden:

<a href='?deletebilder=$slettbildelink&&deletebilder2=$slettbildelink2&&slett=$id2'>Slett</a>

 

Javascriptet:

<script type="text/javascript">
function show_confirm()
{
var r=confirm("Er du sikker på at du vil slette?");
if (r==true)
 {
 alert("Produktet har blitt slettet!");
 }
else
 {
 alert("Produktet ble ikke slettet!");
 }
}
</script>

 

Etter litt søking på nettet, er det slik at jeg ikke kan bruke javascript på en slik lenke? Må jeg til med en annen løsning?

 

 

Edit: Dette er php kode som jeg da skal ha javascriptet på, beklager hvis dette er feilpostet. Såvidt jeg forstår så må jeg til med en annen løsning basert på php kode?

 

 

Mvh.

Endret 23. juli 2011 av haawkon

[xqus]

Du bør uansett ha en PHP sjekk i tillegg tilfelle brukeren har deaktivert javascript. Men emnet hører nok til under JavaScript kategorien.

 

Uansett:

 

<script type="text/javascript">
function show_confirm()
{
var r=confirm("Er du sikker på at du vil slette?");
if (r==true)
 {
 alert("Produktet har blitt slettet!");
 }
else
 {
 alert("Produktet ble ikke slettet!");

 }
 return r;
}
</script>

<a href="http://vg.no" onclick="javascript: return show_confirm();">ok</a>

Endret 23. juli 2011 av xqus

[Ernie]

Å benytte GET i en slik sammenheng er etter min mening feil, og i strid med anbefalinger fra W3C. GET bør aldri benyttes til en forespørsel for å endre noe. Mer om når man benytter GET og POST: http://www.w3.org/2001/tag/doc/whenToUseGet.html

[TheClown]

Det er jo tusen ganger enklere å sende informasjonen gjennom GET, i stede for å begynne å surre med Curl osv. Har man bare sikkerhet på scriptet som kjører har det jo ingenting å si?

[Ernie]

Hva har CURL med saken å gjøre? Her er det jo bare å sette opp en helt vanlig HTML-form i stedet for å balle med javascript. Ønsker man allikevel å benytte javascript kan man vise en lightbox-aktig greie med den samme HTML-form når man trykker på slett.

[FraXinuS]

Det er jo tusen ganger enklere å sende informasjonen gjennom GET, i stede for å begynne å surre med Curl osv. Har man bare sikkerhet på scriptet som kjører har det jo ingenting å si?

Med GET blir det veldig enkelt å utføre CSRF-angrep, spesielt når han ikke bruker noen form for CSRF-beskyttelse.

[TheClown]

Alle oppegående sider må jo sjekke om man er logget inn, da har det jo ingenting å si. POST er like lett å hacke som GET. Handler om å "skjule" informasjonen egentlig.

[Ernie]

… men uansett tilsier jo anbefalinger fra W3C at man ikke benytter GET for parametere som endrer noe. GET skal bare benyttes for oppslag, mens POST også kan medføre endringer. Hvis det etter din mening ikke er noen forskjell i sikkerheten mellom de, er det ikke da mest korrekt å benytte POST til endringer? Hvilke argumenter mener du finnes for å ikke gjøre det?

[FraXinuS]

Alle oppegående sider må jo sjekke om man er logget inn, da har det jo ingenting å si. POST er like lett å hacke som GET. Handler om å "skjule" informasjonen egentlig.

Det hjelper ikke å bare sjekke om man er logget inn, er man allerede logget inn så vil man være logget inn uansett hvor requesten kommer fra. Hvis jeg legger inn et bilde her på forumet med src "example.com/deletebilder=x&deletebilder2=x&slett=x" og noen som er logget inn på den siden besøker forumet vil bildene bli slettet.

 

POST er ikke noe sikrere enn GET, men det gjør det litt vanskeligere. Uansett så er ikke GET den riktige methoden å bruke.

[Cerandin]

Takker for hjelpen xqus!

 

Dere andre mener jeg skal bruke POST funksjonen istedet for GET? Jeg må si jeg ikke henger helt med på hvordan jeg skal kunne gjøre at siden er beskyttet mot CSRF. Og hva har Javascripten å gjøre med at jeg bruker GET? Beklager at jeg er noob og ikke forstår helt hva det er dere mener!

[FraXinuS]

Den mest vanlige måten å beskytte seg mot CSRF er å bruke en unik nøkkel for hver bruker og sende den med requesten som gjør endringer.

En måte å gjøre det på er at du genererer en unik nøkkel for hver bruker og lagrer den i en cookie, også legger du til den nøkkelen i urlene dine.

 

<a href='?deletebilder=$slettbildelink&deletebilder2=$slettbildelink2&slett=$id2&csrf_token=unik-nøkkel'>Slett</a>

 

Før du sletter bildene sjekker du at $_COOKIE['csrf_token'] == $_GET['csrf_token'];

 

Hvis de ikke er like kan det være noen som prøver å lure noen til å slette bildene.

[TheClown]

… men uansett tilsier jo anbefalinger fra W3C at man ikke benytter GET for parametere som endrer noe. GET skal bare benyttes for oppslag, mens POST også kan medføre endringer. Hvis det etter din mening ikke er noen forskjell i sikkerheten mellom de, er det ikke da mest korrekt å benytte POST til endringer? Hvilke argumenter mener du finnes for å ikke gjøre det?

Det er like sikkert, derfor har det pent lite å si. Kan (imo) brukes mot hverandre. W3C sier mye rart, og det er (så og si) ingen som følger deres regler (eller anbefallinger) til punkt og prikke.

 

Hvordan ville du sende informasjon gjennom POST ved å trykke på en link? Da må du vel submite en form, med hidden-felt i seg? Er jo ikke like enkelt å få til, og når kildekoden skrives på den måten, kan den redigeres like enkelt som en URL med GET.

[Jonas]

TheClown: CSRF, CSRF og CSRF. Les og bli vis. Det Ernie og W3C sier om å endre objekter med GET/POST er for øvrig helt korrekt.