Gå til innhold

Hvordan hindre dobbelt posting i gjestebok etc


Anbefalte innlegg

Dette kan vel være ett emne som har vært tatt opp før her, men mitt spørsmål er:

Hvilken metode er den vanligste for å hindre at feks en gjestebok blir spammet med den samme melding over og over igjen..

Jeg har det problemet at dersom noen legger igjen en melding, og deretter klikker på oppfrisk blir den samme meldingen lagt til igjen.. for tiden har jeg en session variable som henter inn tidspunktet for når den første meldingen ble lagret, og dersom en bruker klikker oppfrisk før ett antall sekunder har gått, vil han få en beskjed om at han - hun må vente litt..

 

Synes ikke selv at dette er en god løsning, og vil gjerne høre hvordan andre har gjort dette..

 

PS dette gjelder vel ikke bare gjestebok, men evt lagring av blog og slikt også.

 

På forhånd takk!

Lenke til kommentar
Videoannonse
Annonse

Svarer deg her òg :p

det beste er vel å lage ei fil md formet fks form.php og ei fil som sender innholdet til databasen/tekstfila. Deretter sender du brukeren tilbake til form.php ved hjelp av header

Endret av dabear
Lenke til kommentar

Tja, tidsbegrensning er vel egentlig den beste metoden. Jeg lagrer ikke i en sessionvariabel da, men lagrer postetidspunktet i databasen sammen med meldingen osv, og hvis en person (IP-Adressen) prøver å poste så sjekkes det først opp om han har postet før om hvor lang tid det gikk siden forrige post :)

Lenke til kommentar

Tidsbegrensninger er nok ikke den beste løsningen, i alle fall dersom gjesteboken skulle bli stor. Da må du i alle fall indeksere feltet som lagrer ip adressen.

 

Når du kan løse det mye lettere, og på mye raskere tid med å bruk header("Location:... som dabear foreslår så vil nok den metoden være bedre.

 

Etter du har kjørt query'en som lagrer data i tabellen så sjekker du at mysql_affected_rows ikke er 0 og sender brukeren til siden som viser innlegget deres, med header("Location:... Dersom mysql_affected_rows skulle være 0 betyr dette at det ikke ble satt inn noen rader og du burde du sende brukeren til en error side som forklarer at det er et problem på serveren.

Lenke til kommentar

På en lynrask server med nesten null i responstid vil metoden med å sende ny location gjennom meldingshodene bra. Men som regel er det slik at det tar litt tid før man mottar respons fra siden. I mellomtiden vil da den gamle siden "henge" etter. Resultatet blir da, at man kan ha muligheten til å trykke submitknappen flere ganger. Enten med vilje, eller ved et uhell (trykker inn enter f.eks). Resultatet blir da at man sender flere requests med den samme post-informasjonen. Dette betyr med andre ord mange dobbeltposter.

 

Å bruke Header("Location: ...") hindrer heller ikke brukere i å poste hundrevis av poster etter hverandre med vilje. Det synes jeg personlig er en uting.

 

For at indeksering av ip-adressen skal bli nødvendig, bør gjesteboken bli VELDIG stor.

 

Edit: Vet ikke hvor jeg hadde hodet. Post rettet

Endret av RipZ-
Lenke til kommentar

RipZ-

Du har et poeng med ping tid på serveren, men det nok som regel hos brukeren problemet med treg line ligger. Synes like vel at det er viktig å pointere at det du snakker om er den kjempelille tidsdiferansen browseren bruker på å oppdatere den siden som vises - og det største problemet er neppe det, men problemet med at folk klikker oppdater eller bruker back kanppen. Siden det er det største problemet må man sette en veldig lang "låse" tid på scriptet. Da blir problemet at brukeren ikke kan poste noe nytt. Det er av den grunn at header("Location: er en bedre løsning.

 

Poenget ditt er likevel ikke urelevant, men hvis du ser på mange nettsteder så har de valgt å løse probleme med javascript.

 

Kommentaren din: "For at indeksering av ip-adressen skal bli nødvendig, bør gjesteboken bli VELDIG stor." er vel litt for generell. Så lenge vi ikke kjenner innholdet i tabellen så kan det holde med noen få tusen rader. I en tabell med rundt 10 000 rader vil du begynne å merke det på en liten tabell. Nå er det ikke sikkert at denne tabellen er/blir så stor, men jeg jobber med å utvikle php scripts - så jeg lager ting for at det skal kunne vokse. Videre så synes jeg det er bedre å gjøre det grundig fra bunnen av - slik at du slipper å kjøre en repair table med en tabell som har et par hundre tusen rader. Det er vel uansett få ulemper med å kjøre en index på den fra begynnelsen.

 

Ikke forstå denne posten som en ren motsigelse, alle saker har flere sider - og det med at brukeren kan trykke flere ganger på send er absolutt et poeng som er verdt å merke seg. Å låse brukeren for å kunne poste på nytt hindrer ikke brukeren nok siden det kan hende de trykker back etter en stund for å finne igjen en side. Det er derfor header location er en veldig vanlig løsning som du vil finne igjen i mange scripts.

Endret av ????????
Lenke til kommentar

Å indeksere en rad med flere hundre tusen rader tar faktisk ikke spesielt lang tid. Men selvfølgelig, jeg skjønner poenget ditt :)

 

Om man bruker indeksering på for mange kolonner, tar alle insert-spørringer og liknede lengre tid pga at man må opprette nye indekser hver gang (må sortere ting på nytt). Her er det spørsmål på hvor man skal oppnå best ytelse (ved skriving eller lesing). I en gjestebok er det vel best å opptimalisere for lesing.

 

Jeg er enig i at man alltid skal ta sikte for vekst. Men her er det snakk om en vanlig gjestebok, ikke en større webløsning. Derfor mener jeg det kan være litt overkill :)

 

Jeg bruker ofte å sette ny location, nettopp av den grunn du nevner (at man trykker oppdater osv). Men det betyr likevel ikke at jeg dropper å sikre mine webaplikasjoner mot spam o.l.

 

Jeg tror uansett vi er veldig enig. Det er bare et spørsmål om hva man vil utrette med scriptet. For meg faller en gjestebok under mindre script som man ikke trenger å tenke på optimalisering i samme grad. (Men snakker vi om større gjesteboktjenester som den jeg har på www.nuffe.net, blir plutselig optimalisering veldig viktig :))

Lenke til kommentar

I mitt gjestebok script så sjekker jeg med en spørring om samme melding med samme avsender allerede ligger lagret i mysql databasen før meldingen blir lagt inn. Så om noen vil spamme samme melding, eller trykke oppdater så blir det ikke lagt inn flere enn en lik melding. PHP er en fin ting :)

Lenke til kommentar

Takke for gode svar fra alle her... har fått en del ting å tenke på.. og teste.. :p

 

Men må bli ferdig på jobben først... :roll:

 

Vet jeg prøvde det med header location før, men fikk en feilmelding at header allered var satt... er ikke helt sikker, men tror det kan ha noe med at jeg includer tilfeldig bilde fra menalto galleriet...

 

Takk igjen.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...