---

Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
kommet spam i den. Er der nogen der har en simpel metode til at
forhindre det? Det ville være bedst, hvis jeg ikke skulle ændre
for meget i mine koder.

Mvh. Christoffer

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Christoffer Overgaard wrote:

> Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
> kommet spam i den. Er der nogen der har en simpel metode til at
> forhindre det?

Hvis det er bot'er der laver spam, er det en god ide at ændre 'noget' i
formen vha javascript.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote in dk.edb.internet.webdesign.html:
> Christoffer Overgaard wrote:
>
> > Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
> > kommet spam i den. Er der nogen der har en simpel metode til at
> > forhindre det?
>
> Hvis det er bot'er der laver spam, er det en god ide at ændre 'noget' i
> formen vha javascript.
>
> --
> Med venlig hilsen
> Stig Johansen

Kan du måske være lidt mere specifik med dit svar?

-Christoffer

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Christoffer Overgaard wrote:

> Kan du måske være lidt mere specifik med dit svar?

Det er svært når du ikke har et eksempel.

At ændre 'noget' kunne være URL'en i action, værdien på en knap eller andet,
og tjekke serverside om værdien passer.
Her:
<http://w-o-p-r.dk/wopr.tools/wopr.linkchecker.asp>
har jeg en kombination af javascript og capchta.
Hvis javascript er enabeld, ændres knappen, og hvis ikke, bliver man spurgt
om et spørgsmål.

--
Med venlig hilsen
Stig Johansen

---

Den 13-03-2010 22:53, Christoffer Overgaard skrev:
> Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
> kommet spam i den. Er der nogen der har en simpel metode til at
> forhindre det?

Hvis gæstebogen kun er beregnet til dansktalende, er her en
meget sikker metode: Lav et ekstra indtastningsfelt, og
skriv som forklaring til feltet, hvad der skal skrives i
det. Fx:
Skriv navnet på det dyr, der er på fire bogstaver og som
siger pruh.

I din kode tjekker du så, om der står hest i feltet. Er det
tilfældet, accepteres indlægget. Hvis feltet ikke er udfyldt
korrekt, vises en fejlside.

Du kan få hjælp til den konkrete kode i gruppen
dk.edb.internet.webdesign.serverside.php hvis den ellers
findes på html.dk.

--
Mvh. Kim Ludvigsen
Hold virus, spyware og hackere væk fra computeren:
http://pc-sikkerhed.dk

---

> Hvis gæstebogen kun er beregnet til dansktalende, er her en
> meget sikker metode: Lav et ekstra indtastningsfelt, og
> skriv som forklaring til feltet, hvad der skal skrives i
> det. Fx:
> Skriv navnet på det dyr, der er på fire bogstaver og som
> siger pruh.
>
> I din kode tjekker du så, om der står hest i feltet. Er det
> tilfældet, accepteres indlægget. Hvis feltet ikke er udfyldt
> korrekt, vises en fejlside.
>
> Du kan få hjælp til den konkrete kode i gruppen
> dk.edb.internet.webdesign.serverside.php hvis den ellers
> findes på html.dk.

Tak! Det tror jeg bestemt jeg kan bruge til noget!

-Christoffer

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

Den 13-03-2010 16:53, Christoffer Overgaard skrev:
> Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
> kommet spam i den. Er der nogen der har en simpel metode til at
> forhindre det? Det ville være bedst, hvis jeg ikke skulle ændre
> for meget i mine koder.

I førate omgang og hvis det ikke er en større side (portal ell. lign),
så gør følgende:

Du skal finde den del i din serverside kode, som tjekker på POST, og som
opdaterer dine kommentarer.

Herefter skal du tilføje en yderligere betingelse, et tjek for, om user
forstår GZIP. Jeg har en ASP-ækvivalent, som her er splittet op:

Dim REQUEST_METHOD
Dim ACCEPT_ENCODING

REQUEST_METHOD = request.servervariables("REQUEST_METHOD")
ACCEPT_ENCODING = request.servervariables("HTTP_ACCEPT_ENCODING")

ACCEPT_ENCODING = lCase( ACCEPT_ENCODING)

If REQUEST_METHOD = "POST" and instr( ACCEPT_ENCODING, "gzip") then...

...Her opdateres dine kommentarer...

end if


GZIP: Spambotter forstår ikke GZIP. Alle browsere forstår GZIP

lCase: Man er nødt til at tage en lowercase af accept-encoding, da FF og
IE ikke har samme case.

Men ellers leverer metoden ingen falske negativer, dvs. den udelader
ikke human users. Den er 99.9% sikker den anden vej. Der slippes yderst
sjældent botter igennem.

For brugeren vil oplevelsen være, at der ikke foregår noget tjek, og at
denne ikke skal gøre noget, hvilket er en fordel i forhold til CAPTCHA.
Samtidig, så fylder spamsikringen kun én kodelinje.


MVH
Rune Jensen

---

Den 14-03-2010 10:25, Rune Jensen skrev:

> Herefter skal du tilføje en yderligere betingelse, et tjek for, om user
> forstår GZIP. Jeg har en ASP-ækvivalent, som her er splittet op:
>
> Dim REQUEST_METHOD
> Dim ACCEPT_ENCODING
>
> REQUEST_METHOD = request.servervariables("REQUEST_METHOD")
> ACCEPT_ENCODING = request.servervariables("HTTP_ACCEPT_ENCODING")
>
> ACCEPT_ENCODING = lCase( ACCEPT_ENCODING)
>
> If REQUEST_METHOD = "POST" and instr( ACCEPT_ENCODING, "gzip") then...
>
> ...Her opdateres dine kommentarer...
>
> end if

Dejligt at se hvordan andres kode ser ud. Det er jo dejlig simpelt.

Jeg bruger noget lignende i PHP (inspireret af tidligere tråde her i
nyhedsgrupperne), men i en lidt mere indviklet form (og kører det via en
include på alle formularer). Havde dog ikke fanget den med lcase.
Og heldigvis er det ofte nemt hurtigt at oversætte mellem ASP og PHP.

Direkte oversættelse (er ikke afprøvet i denne form):

$REQUEST_METHOD = $_SERVER["REQUEST_METHOD"];
$ACCEPT_ENCODING = strtolower($_SERVER["HTTP_ACCEPT_ENCODING"]);

if($REQUEST_METHOD == "POST" and strpos($ACCEPT_ENCODING,"gzip") !==
false) {
... her opdateres dine kommentarer ...
}

> For brugeren vil oplevelsen være, at der ikke foregår noget tjek, og at
> denne ikke skal gøre noget, hvilket er en fordel i forhold til CAPTCHA.

Og en af mine kæpheste.

> Samtidig, så fylder spamsikringen kun én kodelinje.

Det bliver vel til 7 linjer ASP, da jeg antager at trådstarter kun har
det der står mellem "if..." og "end if".
Men stadig meget nemt og enkelt.


--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 14-03-2010 14:02, Philip Nunnegaard skrev:
> Den 14-03-2010 10:25, Rune Jensen skrev:

<SNIP: ASP>
> Jeg bruger noget lignende i PHP (inspireret af tidligere tråde her i
> nyhedsgrupperne), men i en lidt mere indviklet form (og kører det via en
> include på alle formularer). Havde dog ikke fanget den med lcase.
> Og heldigvis er det ofte nemt hurtigt at oversætte mellem ASP og PHP.
>
> Direkte oversættelse (er ikke afprøvet i denne form):
>
> $REQUEST_METHOD = $_SERVER["REQUEST_METHOD"];
> $ACCEPT_ENCODING = strtolower($_SERVER["HTTP_ACCEPT_ENCODING"]);
>
> if($REQUEST_METHOD == "POST" and strpos($ACCEPT_ENCODING,"gzip") !==
> false) {
> ... her opdateres dine kommentarer ...
> }

Med ASP-koden ved siden af, er det ikke svært at finde store ligheder.

To spørgsmål dog: Dimensionerer man ikke variable i PHP, inden man
tildeler dem værdi?

Har man tydelig typeforskel på variable, talvariable, strenge i PHP?


>> For brugeren vil oplevelsen være, at der ikke foregår noget tjek, og at
>> denne ikke skal gøre noget, hvilket er en fordel i forhold til CAPTCHA.
>
> Og en af mine kæpheste.

Der er skam mere end spambots, man kan tage via GZIP - tror jeg ;)

Harvesterbots f.eks. henter sidens og ikke mindst formens HTML-kode for
derefter at give denne viden videre til spambots (det er den gammeldaws
facon). Harvesters kendetegnes for en stor dels vedkommende ved, de
forstår ikke GZIP, og useragent starter med JAVA.

Vi lavede engang et ret langstrakt forsøg, som viste dette, og som
svarede ret nøje til:
http://projecthoneypot.org/harvester_useragents.php

Med denne viden kan man teoretisk sende harvesterbots og dermed spambots
falske oplysninger. Man indsætter en betingelse, eksempelvis i formens
action-attribut a la:

<form method="post" action="<%

if (does not understand GZIP) AND (useragent starts with JAVA) then
response.write "URL til honeypot?id=" + unikID
else
response.write "Rigtig URL, som skal bruges ved POST"
end if

%>">

Man kan selvfølgelig også forgifte formfelter i stedet, give dem
forkerte navne f.eks., jeg ville bare gerne først og fremmest have fyldt
lidt på honeypotten.

Jeg lagde dette ind på et par sider i går, de næste par dage vil vise,
om det virker efter hensigten.


>> Samtidig, så fylder spamsikringen kun én kodelinje.
>
> Det bliver vel til 7 linjer ASP, da jeg antager at trådstarter kun har
> det der står mellem "if..." og "end if".
> Men stadig meget nemt og enkelt.

Det er rigtigt, der er langt flere kodelinjer ;) Men de linjer som
fylder i ASP-eksemplet sætter globale variable, som jeg også kan bruge
senere. Det er faktisk noget, jeg har på alle mine sider nu som fast
bestanddel uanset.

Grunden er, at hentning af servervariable iflg. Microsoft er en ret
krævende handling for performance. Så jeg henter samtlige servervariable
én gang for alle i den allerførste include og bevarer deres værdi i
variable, som jeg så kan bruge overalt i stedet.

For at vise, de er globale variable og ikke må ændres, skriver jeg dem
så med stort, men ASP er ligeglad med case idfb. Normalt tror jeg ikke,
man anbefaler globale variable, men lige her, synes jeg det er OK.


MVH
Rune Jensen

---

Den 15-03-2010 00:56, Rune Jensen skrev:

> To spørgsmål dog: Dimensionerer man ikke variable i PHP, inden man
> tildeler dem værdi?

Jeg må være dig svar skyldig, men jeg har ikke umiddelbart set det i
forskellige kodeeksempler.

Men jeg skal også indrømme at det var uhyre sjældent at jeg gjorde det i
ASP. Det fungerede fint uden.
Af samme grund tør jeg ikke sige med 100% sikkerhed at man ikke også gør
det i PHP.

> Har man tydelig typeforskel på variable, talvariable, strenge i PHP?

Nok ikke SÅ forskelligt fra ASP. Og dog:
Jeg oplevde i ASP at den nogle gange kunne komme til at opfatte en
talvariabel som en streng. Det løste jeg gerne ved at skrive noget a la:

tal = tal + 0

Det virker på mig som om PHP umiddelbart opfatter rene tal som talvariabler.

Men ikke mere end at man kan lægge et tal og en streng sammen, så det
bliver til en ny streng:

$nystreng = $tal . " " . $streng; // returnerer f.eks. "83tekst"

Og jeg kan fortsat behandle $tal som et tal.


--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard wrote:

> Jeg oplevde i ASP at den nogle gange kunne komme til at opfatte en
> talvariabel som en streng. Det løste jeg gerne ved at skrive noget a la:
>
> tal = tal + 0

Det handler lidt om typestærke, og typesvage sprog, samt 'automagisk'
typekonvertering 'under the hood'.

ASP,PHP og javascript er typesvage, og derfor er det let at falde i fælden.

Et eksempel(javascript):
<http://w-o-p-r.dk/test/type.sprog.html>
hvor s og t bege har værdien 1, men afhængig af den videre behandling for
man 2 vidt forskellige resultater (2 vs. 11)

Det er ikke altid det er en fordel, at det er nemt at skrive, hvis det er
svært at fejlfinde.

--
Med venlig hilsen
Stig Johansen

---

Den 15-03-2010 09:18, Stig Johansen skrev:

> hvor s og t bege har værdien 1, men afhængig af den videre behandling for
> man 2 vidt forskellige resultater (2 vs. 11)

Her er problemet vel at man i javascript lægger værdier sammen med '+',
uanset om man lægget tal sammen eller stykker strenge sammen.

I ASP og PHP har jeg brugt '+' til at lægge tal sammen og hhv. '&' og
'.' til at stykke strenge sammen.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard wrote:

> Her er problemet vel at man i javascript lægger værdier sammen med '+',
> uanset om man lægget tal sammen eller stykker strenge sammen.

Jeg ser det mere som problemet med typesvage sprog.

> I ASP og PHP har jeg brugt '+' til at lægge tal sammen og hhv. '&' og
> '.' til at stykke strenge sammen.

Man kan godt kode typestærkt i ASP:
'1' + '2' = '12'
1+2=3
'1'+2 = fejl

(bruger ikke & i ASP af samme årsag).

--
Med venlig hilsen
Stig Johansen

---

Den 15-03-2010 14:39, Stig Johansen skrev:

> Man kan godt kode typestærkt i ASP:

Hvad mener du med typestærkt?
Og hvordan får man den til at fatte at det er tallet 2 og ikke strengen '2'?

> '1' + '2' = '12'
> 1+2=3
> '1'+2 = fejl
>
> (bruger ikke& i ASP af samme årsag).

Jeg kendte ikke til andet end '&', før du for et par dage siden postede
et indlæg hvor du brugte '+'.


--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Philip Nunnegaard wrote:

> Hvad mener du med typestærkt?

Typestærke sprog tjekker typerne - helst på kompileeringstidspunktet - så
man får fejl hvis man prøver at lægge f.eks. en streng og et tal sammen, i
steedt for 'sjove' resultater.

> Og hvordan får man den til at fatte at det er tallet 2 og ikke strengen
> '2'?

Hvis det er input fra en form, og ASP:
Tallet = cInt(Request.Form("feltet"))

--
Med venlig hilsen
Stig Johansen

---

Den 15-03-2010 16:03, Philip Nunnegaard skrev:
> Den 15-03-2010 14:39, Stig Johansen skrev:
>
>> Man kan godt kode typestærkt i ASP:
>
> Hvad mener du med typestærkt?
> Og hvordan får man den til at fatte at det er tallet 2 og ikke strengen
> '2'?
>
>> '1' + '2' = '12'
>> 1+2=3
>> '1'+2 = fejl
>>
>> (bruger ikke& i ASP af samme årsag).
>
> Jeg kendte ikke til andet end '&', før du for et par dage siden postede
> et indlæg hvor du brugte '+'.

Jeg har lavet en forklaring til ASP. Måske én kan af- eller bekræfte.

Testside kan ses her:
http://www.webdesigngruppen.dk/designteknik/asp_operators.asp

Måske en tilsvarende i PHP og Js er mulig.


MVH
Rune Jensen

---

Rune Jensen skrev:
> Den 15-03-2010 16:03, Philip Nunnegaard skrev:
>> Den 15-03-2010 14:39, Stig Johansen skrev:
>>
>>> Man kan godt kode typestærkt i ASP:
>>
>> Hvad mener du med typestærkt?
>> Og hvordan får man den til at fatte at det er tallet 2 og ikke strengen
>> '2'?
>>
>>> '1' + '2' = '12'
>>> 1+2=3
>>> '1'+2 = fejl
>>>
>>> (bruger ikke& i ASP af samme årsag).
>>
>> Jeg kendte ikke til andet end '&', før du for et par dage siden postede
>> et indlæg hvor du brugte '+'.
>
> Jeg har lavet en forklaring til ASP. Måske én kan af- eller bekræfte.
>
> Testside kan ses her:
> http://www.webdesigngruppen.dk/designteknik/asp_operators.asp
>
> Måske en tilsvarende i PHP og Js er mulig.
>
>
> MVH
> Rune Jensen

I PHP lægges tal sammen med + og strenge concateneres - sættes sammen -
med .
PHP konverterer variablene som nødvendigt.
$a = 2; // alle php variable begynder med $
$b = '4'; eller $b = "4";
$a + $b = 6 tallet seks
$a.$b = '24' en tekststreng
$a.$b.($a+$b) = '246' en tekststreng.
I PHP er det operatoren der bestemmer typen af resultatet (tal eller
numerisk). Den numeriske type, er integer hvis muligt, ellers float.

Streng til tal konvertering, sker ved at PHP tager hvad der kan passe
med et tal, fra ventre. Er der ikke noget, er værdien 0. Dog bruges
bogstavet e til potenser (eksponent): '10E3' = '10e3' = 1000 Der kan
være + eller - foran, og der kan være decimaler (og kommaet, som vi
kalder decimaltegnet, er et punktum!). Alt andet fjernes uden
yderligere varsel.

I JS, bruges + både som aritmetisk operator og concatenator.
ECMA-262:
"11.6.1 The Addition operator ( + )
The addition operator either performs string concatenation or numeric
addition.
The production AdditiveExpression : AdditiveExpression +
MultiplicativeExpression is evaluated as follows:
1. Let lref be the result of evaluating AdditiveExpression.
2. Let lval be GetValue(lref).
3. Let rref be the result of evaluating MultiplicativeExpression.
4. Let rval be GetValue(rref).
5. Let lprim be ToPrimitive(lval).
6. Let rprim be ToPrimitive(rval).
7. If Type(lprim) is String or Type(rprim) is String, then
a. Return the String that is the result of concatenating
ToString(lprim) followed by ToString(rprim)
8. Return the result of applying the addition operation to
ToNumber(lprim) and ToNumber(rprim). See the Note below 11.6.3.
NOTE 1 No hint is provided in the calls to ToPrimitive in steps 5 and
6. All native ECMAScript objects except Date objects handle the absence
of a hint as if the hint Number were given; Date objects handle the
absence of a hint as if the hint String were given. Host objects may
handle the absence of a hint in some other manner.
NOTE 2 Step 7 differs from step 3 of the comparison algorithm for the
relational operators (11.8.5), by using the logical-or operation
instead of the logical-and operation."
Noten efter 11.6.3 siger at a-b er det samme som a+(-b) ( 7+'-3' er
altså 4)

For mig står der, at js returnerer en streng, hvis ikke begge operander
er tal.
Og det passer også meget godt med den opfattelse jeg har af det, ved at
arbejde med det, selvom man af og til bliver overrasket. Jeg har ingen
eksempler på stående fod, så..

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Rune Jensen wrote:

> Jeg har lavet en forklaring til ASP. Måske én kan af- eller bekræfte.
>
> Testside kan ses her:
> http://www.webdesigngruppen.dk/designteknik/asp_operators.asp

Den her:
.....
Er det derimod en strenvariabel og en talvariabel, bliver de begge om muligt
opfattet som talvariable, a + c = 5.
.....
Bør også give en 'type mismatch error'.

--
Med venlig hilsen
Stig Johansen

---

Den 16-03-2010 03:14, Stig Johansen skrev:
> Rune Jensen wrote:
>
>> Jeg har lavet en forklaring til ASP. Måske én kan af- eller bekræfte.
>>
>> Testside kan ses her:
>> http://www.webdesigngruppen.dk/designteknik/asp_operators.asp
>
> Den her:
> ....
> Er det derimod en strenvariabel og en talvariabel, bliver de begge om muligt
> opfattet som talvariable, a + c = 5.
> ....
> Bør også give en 'type mismatch error'.

Jeg har body-koden her i .txt-format:
http://www.webdesigngruppen.dk/temp/asp_operators.txt

Jeg har forsøgt så vidt muligt at lade maskinen selv regne det ud, det
er mest ærligt, men det betyder ikke, der ikke kan være fejl... Jeg vil
tage gladeligt imod alle forslag til forbedringer.

;)


MVH
Rune Jensen

---

Rune Jensen wrote:

> Den 16-03-2010 03:14, Stig Johansen skrev:
>> Bør også give en 'type mismatch error'.

Ud fra dit eksempel, så 'Let me rephrase': bør -> burde.

> Jeg har body-koden her i .txt-format:
> http://www.webdesigngruppen.dk/temp/asp_operators.txt

Det kan jeg godt se, og det viser _netop_ problemstillingen med typesvage
sprog.

Det kan være nemt at lave(bruge), men kan være et helvede at fejlfinde i.

Den fundamentale problemstilling er, at man overlader alt for meget
'automagic' til compiler/fortolker, uden selv at vide/have styr på hvad der
forgår 'under the hood'.

--
Med venlig hilsen
Stig Johansen

---

Philip Nunnegaard forklarede den 15-03-2010:
> Den 15-03-2010 00:56, Rune Jensen skrev:
>
>> To spørgsmål dog: Dimensionerer man ikke variable i PHP, inden man
>> tildeler dem værdi?
>
> Jeg må være dig svar skyldig, men jeg har ikke umiddelbart set det i
> forskellige kodeeksempler.
>
> Men jeg skal også indrømme at det var uhyre sjældent at jeg gjorde det i ASP.
> Det fungerede fint uden.
> Af samme grund tør jeg ikke sige med 100% sikkerhed at man ikke også gør det
> i PHP.
>
>> Har man tydelig typeforskel på variable, talvariable, strenge i PHP?
>
> Nok ikke SÅ forskelligt fra ASP. Og dog:
> Jeg oplevde i ASP at den nogle gange kunne komme til at opfatte en
> talvariabel som en streng. Det løste jeg gerne ved at skrive noget a la:
>
> tal = tal + 0
>
> Det virker på mig som om PHP umiddelbart opfatter rene tal som talvariabler.
>
> Men ikke mere end at man kan lægge et tal og en streng sammen, så det bliver
> til en ny streng:
>
> $nystreng = $tal . " " . $streng; // returnerer f.eks. "83tekst"
>
> Og jeg kan fortsat behandle $tal som et tal.

Variabler skal ikke dimensioneres i PHP. De oprettes når de tildeles en
værdi (initialiseres).
Bruger man en ikke initialiseret variabel, får man en E_NOTICE -
programmet fortsætter, og tildeler variablen en defaultværdi, af en
type der passer i sammenhængen.

Hvis man nu lader være med at "lægge tekster sammen", men i stedet
sammenkæder dem (concatenate, som er det rigige navn for .), er det
lettere at undgå fejl, og at "komme til" at bruge den forkerte.
Hvis $a = 1 og $b = 3 er $a.$b = 13 mens $a+$b = 4
Dette i modsætning til js, der bruger + til sammenkædning af strenge;
man ved ikke hvad man får, bortset fra, at det sandsynligvis er det
forkerte...

Birger

--
http://varmeretter.dk - billig, sund og hurtig mad
http://bbsorensen.dk

---

Den 15-03-2010 00:56, Rune Jensen skrev:

> Der er skam mere end spambots, man kan tage via GZIP - tror jeg ;)

Og jeg har gået lidt med tanken om at bruge den test til også at fange
referer spambots. Til min overraskelse, kan den ikke bruges til dette,
da referer spambots tit opgiver GZIP i ACCEPT_ENCODING.

Men det er ikke svært at se heller, hvorfor, de kan det, og at det er
fake. De skal jo ikke hente siden for at kunne aflevere deres spam, de
skal bare aflevere headeren med den falske referer i. I virkeligheden
kunne de derfor nøjes med at requeste med en HEAD, det vil gå rigtigt
hurtigt, men måske folk vil blive mistænksommme så.

Anyways, de her botmagere er fuldt ud klar over deres handicap med GZIP,
det er ret sikkert, så det er fordi det vil koste dem rigtigt dyrt at få
lavet vedblivende botter som forstår GZIP og som kan skjule sig for
antivirus hvor de er installeret, at vi ikke ser disse botter i større grad.


MVH
Rune Jensen

---

Den 14-03-2010 14:02, Philip Nunnegaard skrev:

> Jeg bruger noget lignende i PHP (inspireret af tidligere tråde her i
> nyhedsgrupperne), men i en lidt mere indviklet form (og kører det via en
> include på alle formularer). Havde dog ikke fanget den med lcase.

Det kan godt være, jeg har taget fejl lige her, men jeg har altid brugt
lCase, og det var sådan jeg husker det. Under alle omstændigheder er der
så store forskelle på de forskellige browsere, at jeg synes, man bare
skal bruge lcase altid...

Nuvel, omkring GZIP... der er nogle ganske få "browsere", som ikke
forstår GZIP (eller ikke forstod det førhen), og med den angivne kode,
vil de derfor ikke kunne POSTe. Spørgsmålet er, om de browsere er så
vigtige at kunne POSTe fra, det må man så bedømme..

Her er en liste, hvor alle browsere er testet for acceptencoding:

http://www.computec.ch/projekte/browserrecon/?s=database&t=&f=accept-encoding

....og her er mine forklaringer til dem, hvor GZIP ikke er med:

Amaya: Jeg har prøvet at installere den, og sidste nye version fra
december 2009 forstår GZIP. Det er iøvrigt ikke bare en "browser", nok
nærmere en slags "editor" tillige, end noget man først og fremmest
browser med. Hjemmeside:
http://www.x-web.org/w3c/amaya/

Massive Inc. Adclient 1.0: Dette er ikke en browser, men en slags shell
(skjult "overlags"program) til at styre reklamer i onlinespil. Den er
automatisk, og som jeg læser det, kan man derfor ikke "browse" selv:
http://nationalcheeseemporium.org/

Opera 9.21: Egentlig er jeg tilbøjelig til at mene, dette er en fejl,
men OK. Denne browserversion må føles ret langsom, hvis det er korrekt.
Desuden er der flere security updates i de følgende versioner, så man
står sig nok under alle omstændigheder bedre med en nyere version (den
er fra 2007). Her er Operas Changelog:
http://www.opera.com/docs/history/#o921

Sony Playstation: Nogen som har prøvet at gå på nettet fra en sådan og
browse - og hvordan klarer den det? Forstår den CSS og JS? Hvad med
cookies? Jeg kan ikke tjekke den, har ikke playstation... men kan
forestille mig den er langsom ;)

Worio: Dette er heller ikke en browser, men en søgebot fra Yet Another
Search Engine To End All Search Engines:
http://www.worio.com/search/

....og for nu at runde af, så er det, at en browser forstår GZIP
simpelthen en nødvendighed i dag af hensyn til hastighed. Hvis den ikke
forstår GZIP, så bliver det, den henter med alt overvejende
sandsynlighed i rå form, hvilket kan betyde mærkbar længere downloadtid,
og det vil ingen browserfabrikant med respekt for sig selv risikere.
Hastighed er vitterligt et issue/konkurrenceparameter, så GZIP er kommet
for at blive. Der er nogle få andre pakke-formater, men tvivler altså
på, de vil erstatte GZIP, nok mere supplere.


MVH
Rune Jensen

---

Den 15-03-2010 02:49, Rune Jensen skrev:
> Den 14-03-2010 14:02, Philip Nunnegaard skrev:
>
>> Jeg bruger noget lignende i PHP (inspireret af tidligere tråde her i
>> nyhedsgrupperne), men i en lidt mere indviklet form (og kører det via en
>> include på alle formularer). Havde dog ikke fanget den med lcase.
>
> Det kan godt være, jeg har taget fejl lige her, men jeg har altid brugt
> lCase, og det var sådan jeg husker det.

Det jeg mente, var at jeg ikke havde fanget at browserne havde de forskelle.

--
Philip - http://www.chartbase.dk | http://www.hitsurf.dk

---

Den 14-03-2010 14:02, Philip Nunnegaard skrev:

> Direkte oversættelse (er ikke afprøvet i denne form):

OK, men jeg har alligevel taget mig den frihed at stjæle dit script (jeg
kan ikke selv teste PHP, men håber andre vil). Jeg har så lavet en side
her, hvor man kan læse baggrunden for det, og hvordan det bruges (ikke
vildt avanceret, bare 1-2 skærmsider):

http://www.webdesigngruppen.dk/designteknik/anti_spam_gzip.asp


MVH
Rune Jensen

---

Christoffer Overgaard wrote:
> Hej, jeg har en simpel PHP gæstebog på min side. Der er desværre
> kommet spam i den. Er der nogen der har en simpel metode til at
> forhindre det? Det ville være bedst, hvis jeg ikke skulle ændre
> for meget i mine koder.

Først etablerer du et ekstra <inputfelt type="text" name="subject"
class="fyfy">

Så sørger du i css for, at det felt ikke ses af almindelige dødelige - de
bruger browsere.

Til sidst tjekker du i php, at feltet ikke er udfyldt:

<?
if (!empty($_POST['subject'])) {
header ("Location: blokeret.php");
exit;
}
?>

.... indsættes øverst i det script, der fra formularen modtager og behandler
data.

--
Med venlig hilsen
Erik Ginnerskov
http://ginnerskov.dk - http://html-faq.dk