---

Når man retter og tilføre nyt på ens webside, skal man tit opdater (F5)
hvad hvis brugerne ikke lige ved at de skal opdater?
hvad kan man gøre så det automatisk sker

JbP

---

oz7aik wrote in dk.edb.internet.webdesign.html:
> Når man retter og tilføre nyt på ens webside, skal man tit opdater (F5)
> hvad hvis brugerne ikke lige ved at de skal opdater?
> hvad kan man gøre så det automatisk sker
>
> JbP
>
Brugernes browser skulle automatisk hente den "nye" side frem, det er kun
fordi at når du redigerer siden, så kommer det ikke frem uden at du
reloader. Det er egentlig naturligt nok.

PerR

--
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

---

"Per Rasmussen" <jegskalgive@dig.dk> skrev i meddelelsen
news:4b33945e$0$275$14726298@news.sunsite.dk...
> oz7aik wrote in dk.edb.internet.webdesign.html:
>> Når man retter og tilføre nyt på ens webside, skal man tit opdater (F5)
>> hvad hvis brugerne ikke lige ved at de skal opdater?
>> hvad kan man gøre så det automatisk sker
>>
>> JbP
>>
> Brugernes browser skulle automatisk hente den "nye" side frem, det er kun
> fordi at når du redigerer siden, så kommer det ikke frem uden at du
> reloader. Det er egentlig naturligt nok.
>
> PerR
>
> --
> 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

tak for hjælpen

forsat god jul

JbP oz3jbp jørgen

---

oz7aik skrev:

> hvad kan man gøre så det automatisk sker

Prøv forslaget på http://html-faq.dk/1006.asp

--
Allan Vebel
http://vebel.dk | http://html-faq.dk

---

>> hvad kan man gøre så det automatisk sker
>
> Prøv forslaget på http://html-faq.dk/1006.asp

Det er noget pjat, så skal brugeren hente en masse ned blot for at der er
ændret en smugle...

Brug AJAX og hent kun det nye indhold, så er det ikke opsætningen, grafik,
ect. der skal hentes igen...

Man kan bruge dit trix på den side med det dynamiske indhold...

Christian

---

"Christian Kragh" <tursoe@gmail.com> skrev i meddelelsen
news:4b35d1a9$0$278$14726298@news.sunsite.dk...
>>> hvad kan man gøre så det automatisk sker
>>
>> Prøv forslaget på http://html-faq.dk/1006.asp
>
> Det er noget pjat, så skal brugeren hente en masse ned blot for at der er
> ændret en smugle...
>
> Brug AJAX og hent kun det nye indhold, så er det ikke opsætningen, grafik,
> ect. der skal hentes igen...
>
> Man kan bruge dit trix på den side med det dynamiske indhold...
>
> Christian

Tak for alle svarene

hvad er AJAX.?

ps. jeg bliver nok aldrig færdig med mine sider, rette stavefejl, nye love
m.m.

JbP

http://www.oz7aik.dk/faglig/

---

>>>> hvad kan man gøre så det automatisk sker
>>> Prøv forslaget på http://html-faq.dk/1006.asp
>> Det er noget pjat, så skal brugeren hente en masse ned blot for at der er
>> ændret en smugle...

>> Brug AJAX og hent kun det nye indhold, så er det ikke opsætningen,
>> grafik, ect. der skal hentes igen...
>> Man kan bruge dit trix på den side med det dynamiske indhold...

> Tak for alle svarene
> hvad er AJAX.?

Ajax er hvor man henter indhold til et element, i mit tilfælde to div
elementer med id thumbcontent og en med piccontent.

Du kan se neders på siden, hvis du viser kildekoden, at jeg henter indhold
fra eksterne sider med javascript.

Hvis du prøver at hente den side der hedder welcome.asp så vises indholdet
som også vises på forsiden.
Derfor kan man nemt ændre indholdet uden at designet skal hentes igen...
Alle billeder, CSS filer, ect. er jo allerede hentet.

> ps. jeg bliver nok aldrig færdig med mine sider, rette stavefejl, nye love
> m.m.

Det bliver vi andre heller ikke nogen sinde...

Christian

---

Ja, og siden jeg tænkte på er jo selvfølgelig: http://www3.ckweb.dk/

Christian

---

"Christian Kragh" <tursoe@gmail.com> skrev i meddelelsen
news:4b366802$0$280$14726298@news.sunsite.dk...
> Ja, og siden jeg tænkte på er jo selvfølgelig: http://www3.ckweb.dk/
>
> Christian
tak alle sammen, nu bliver det for svært for mig.
gælder det også når alle mine sider er "selvstændig" sider, med link til
mapper hvor der er index fil.

Skal man for øvrigt skrive hele stigen eller nøjes med .\side

ps. bær over med mig jeg har ikke lært CSS i nu, det kommer nok en gang

JbP
http://www.oz7aik.dk/faglig/

---

>> Christian
> tak alle sammen, nu bliver det for svært for mig.
> gælder det også når alle mine sider er "selvstændig" sider, med link til
> mapper hvor der er index fil.

Jeg har lavet en side med designet, med link til alle mine undersider med
mit indhold.
Når der skal vises noget så trykker man på et link, som henter det indhold
til det element man ønsker at vise det i...

> Skal man for øvrigt skrive hele stigen eller nøjes med .\side

Du skal bruge hele stien, da den ikke kan finde ud af andet...
Det er jo en Javascript motor der skal hente indholdet og den kender ikke
til så meget...

> ps. bær over med mig jeg har ikke lært CSS i nu, det kommer nok en gang

Det går nok, da vi alle starter et sted, for at bevæge os videre...

---

"Christian Kragh" <tursoe@gmail.com> skrev i meddelelsen
news:4b368041$0$278$14726298@news.sunsite.dk...
>>> Christian
>> tak alle sammen, nu bliver det for svært for mig.
>> gælder det også når alle mine sider er "selvstændig" sider, med link til
>> mapper hvor der er index fil.
>
> Jeg har lavet en side med designet, med link til alle mine undersider med
> mit indhold.
> Når der skal vises noget så trykker man på et link, som henter det indhold
> til det element man ønsker at vise det i...
>
>> Skal man for øvrigt skrive hele stigen eller nøjes med .\side
>
> Du skal bruge hele stien, da den ikke kan finde ud af andet...
> Det er jo en Javascript motor der skal hente indholdet og den kender ikke
> til så meget...
>
>> ps. bær over med mig jeg har ikke lært CSS i nu, det kommer nok en
>> gang
>
> Det går nok, da vi alle starter et sted, for at bevæge os videre...

hej igen
det jeg mener med hele stigen, 'http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm
eller ../xxxxxxx/xxxxxxx/index.htm

JbP

---

> hej igen
> det jeg mener med hele stigen, 'http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm
> eller ../xxxxxxx/xxxxxxx/index.htm

Det rigtige er:
http://www.xxxxxxxxxxx.xx/xxxxxx.index.htm

Den spørger efter en specifik adresse som skal være hel... ligesom hvis du
kopierede den fra adresselinjen...

---

oz7aik skrev:

> hvad er AJAX.?

Det er bl.a. det, som sørger for at give sig flere forslag, når du
skriver et søgeord i Google.

Prøv f.ek.s at bare skrive ordet AJAX i Google søgefeltet, så dukker en
underliste op med de mest søgte ord i forbindelse med ordet AJAX. Bl.a.
AJAX Tutorial og AJAX Amsterdam..

AJAX er en blanding af javascript og serverside.

Javascripten holder øje med, hvad du skriver, og kontakter et serverside
script, som (i dette tilfælde) kigger igennem en database for at finde
matches til dine ord, og hvis den finder det, sender den det tilbage til
javascriptet, som så kan udskrive listen. At have hele databasen
clientside ville være altfor stort. Den skulle jo så sendes med hver
side til hver bruger. På denne måde deler man i stedet arbejdet imellem
klienten og serveren.

Bagdelen ved AJAX er, der bruges javascript. Derfor vil du heller ikke
kunne se det, hvis du har javascript slået fra. Man skal også være
opmærksom på, hvordan AJAX bruges på mobiler. Opera Mini sender først en
side igennem en sekundær server, før den sendes til mobilen (for at
"mobiloptimere" siden), derfor er AJAX ikke optimalt på mobiler, og man
bør have en fall-back i så fald. Jeg ved ikke, om der er en teknisk
løsning på dette i nær fremtid fra Opera.

Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer en
del af siden, ikke hele siden. Adresselinjen ændres derfor heller ikke.
Men det går langt hurtigere end at opdatere hele siden.

Det er nøjagtigt samme princip som Google som rejseplanen.dk bruger, når
du skriver en adresse.

Og jeg tror faktisk både gmail, hotmail og facebook bruger det ret
intensivt til deres chat/mailsystem. Det har ret mange muligheder.


MVH
Rune jensen

---

Rune Jensen skrev:

>> hvad er AJAX.?
>
> Det er bl.a. det, som sørger for at give sig flere forslag, når du
> skriver et søgeord i Google.

Asyncrone Javascript And XML.
Men selv bruger jeg aldrig XML, så ACAS ville være tættere på min brug
(Asyncrone Clientside And Serverside), jævnfør din egen forklaring:

> AJAX er en blanding af javascript og serverside.

> Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer en
> del af siden, ikke hele siden. Adresselinjen ændres derfor heller ikke.
> Men det går langt hurtigere end at opdatere hele siden.

Så vi har lidt de samme overvejelser som med de gamle frames. Jeg ville
aldrig lade hele navigeringen være baseret på AJAX, da man dermed ikke
kan deeplinke til en underside uden at skulle højreklikke på et link og
rekonstruere sig til en URL derfra, sådan som man også skulle med
frame-sider i gamle dage.

Men efter min mening helt fint til Googles søgefelt samt til andre ting
der ikke skal deeplinkes til (f.eks. administrationsværktøjer).

> Og jeg tror faktisk både gmail, hotmail og facebook bruger det ret
> intensivt til deres chat/mailsystem. Det har ret mange muligheder.

Facebook ser ud til at bruge det hæftigt. Det kan kun være det der gør
at jeg kan skrive en kommentar til en statusmeddelelse og efterfølgende
se min kommentar på siden uden at hele siden bliver genindlæst.
Jeg kender hverken Gmail eller Hotmail andet end af navn, men det glæder
mig da hvis http-mail er blevet lidt nemmere at danse med, end de var da
jeg prøvede webmail af for 6-8 år siden.


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

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>>> hvad er AJAX.?
>>
>> Det er bl.a. det, som sørger for at give sig flere forslag, når du
>> skriver et søgeord i Google.
>
> Asyncrone Javascript And XML.

Ja. Jeg synes bare, hvis man ikke ved, hvad AJAX er, ved man måske
heller ikke hvad XML er, så jeg gik mere op i selve funktionen ;)

Og så ved jeg ikke særligt meget om XML heller.

> Men selv bruger jeg aldrig XML, så ACAS ville være tættere på min brug
> (Asyncrone Clientside And Serverside), jævnfør din egen forklaring:
>
>> AJAX er en blanding af javascript og serverside.
>
>> Fordelene og mest kendetegnende ved AJAX er nok, at man kun opdaterer
>> en del af siden, ikke hele siden. Adresselinjen ændres derfor heller
>> ikke. Men det går langt hurtigere end at opdatere hele siden.
>
> Så vi har lidt de samme overvejelser som med de gamle frames.

Jaaa... men man kan lave nogle dirty-tricks med AJAX også, ligesom man
kan med frames. Jeg kan ikke huske baggrunden, men det er noget med at
ændre # værdien. Altså sætte en ny værdi ind sidst i URLen for hver
opdatering. På den måde kan man ændre adresselinjen uden hele siden
indlæses igen og bruge frem/tilbage-knappen.

> Jeg ville
> aldrig lade hele navigeringen være baseret på AJAX, da man dermed ikke
> kan deeplinke til en underside uden at skulle højreklikke på et link og
> rekonstruere sig til en URL derfra, sådan som man også skulle med
> frame-sider i gamle dage.

Nej, men hovedproblemet ligger i, hvis JS er slået fra, og så det med
mobiler. Men man kan altid kode sig ud af det. Eller lave det som ren
HTML/CSS med JS som en overbygning (men så ved jeg ikke rigtigt med
AJAX, så er det måske mere ren JS).

> Men efter min mening helt fint til Googles søgefelt samt til andre ting
> der ikke skal deeplinkes til (f.eks. administrationsværktøjer).

Googles søgefelt er rigtigt godt eksempel på unobtrusive design. Du
mister en funktion uden JS slået til, men man kan fint bruge siden
alligevel.

> Facebook ser ud til at bruge det hæftigt. Det kan kun være det der gør
> at jeg kan skrive en kommentar til en statusmeddelelse og efterfølgende
> se min kommentar på siden uden at hele siden bliver genindlæst.

Ja, jeg kan heller ikke tro andet.

> Jeg kender hverken Gmail eller Hotmail andet end af navn, men det glæder
> mig da hvis http-mail er blevet lidt nemmere at danse med, end de var da
> jeg prøvede webmail af for 6-8 år siden.

Det er det. Og nu kan jeg ikke huske, om det er Hotmail eller Gmail
eller begge, men der er mulighed for at bruge det både med og uden
JS/AJAX. Der er sådan en "classic" indstilling. Og det er ret godt tænkt.


MVH
Rune Jensen

---

Philip Nunnegaard kom med denne ide:
8X
> Facebook ser ud til at bruge det hæftigt. Det kan kun være det der gør at jeg
> kan skrive en kommentar til en statusmeddelelse og efterfølgende se min
> kommentar på siden uden at hele siden bliver genindlæst.
8X

Man kan sagtens udskifte tekst på en side, uden at anvende AJAX, ved
brug af clentside scripting (javascript) - det kniber nok mere med at
få den fra clienten til serveren, uden at siden genindlæses, uden brug
af AJAX.
Man kan godt forestille sig at Facebook har udviklet deres egne
objecter til den slags - men formentlig brug de browsernes indbygge -
altså "AJAX".

Birger

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

---

Philip Nunnegaard wrote:

> Asyncrone Javascript And XML.
> Men selv bruger jeg aldrig XML, så ACAS ville være tættere på min brug

Jeg bruger Synkron JS og Text et sted, så det må være SJAT :)

Bortset fra det, skal man også have in mente, at disse ting ikke bliver læst
af søgemaskinerne.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Philip Nunnegaard wrote:
>
>> Asyncrone Javascript And XML.
>> Men selv bruger jeg aldrig XML, så ACAS ville være tættere på min brug
>
> Jeg bruger Synkron JS og Text et sted, så det må være SJAT :)

He, jaaaa...

Jeg har undret mig over, hvad det så hedder serverside.

Jeg bruger XMLHTTPObejctet til at hente en side serverside, for at
strippe HTMLen, og her bruger jeg ASP.

Er det så AAAX?

Eller måske nærmere AAAH.. for det er ikke XML.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Er det så AAAX?
>
> Eller måske nærmere AAAH.. for det er ikke XML.

Jeg tror egentlig at det jeg bruger, er noget som kaldes AHAH
(Asychronous HTML and HTTP), men i daglig tale kalder jeg det bare "AJAX".
Jeg trigger en php-fil via et javascript, og denne php-fil sender et
output tilbage til en bestemt id på siden (f.eks. en <div>).

Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
på hvor jeg bruger det.

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

---

Philip Nunnegaard skrev:

> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
> på hvor jeg bruger det.

Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at være
samme fremgangsmåde hver gang, så jeg også har en chance for at forstå
det.. og i så fald laver jeg sgu' hele sitet unobtrusive, bare for
lirens skyld.

Men man skal nok ikke sige for meget på forhånd ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
> lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at være
> samme fremgangsmåde hver gang, så jeg også har en chance for at forstå
> det.. og i så fald laver jeg sgu' hele sitet unobtrusive, bare for
> lirens skyld.
>
> Men man skal nok ikke sige for meget på forhånd ;)

Jeg troede ellers at du havde rimeligt styr på det.
Javascript er ikke min stærke side, så indtil videre lever jeg bare med
en masse inline-js-kald, selvom det giver en masse frygteligt
uoverskuelig kode.

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

---

Philip Nunnegaard wrote:

> Rune Jensen skrev:
>
>> Jeg er i gang med at lege lidt med de eventhandler-functions, Stig har
>> lavet. Det _ser ud_ som om, det er ret let, dvs. det lader til at være
>> samme fremgangsmåde hver gang, så jeg også har en chance for at forstå
>> det.. og i så fald laver jeg sgu' hele sitet unobtrusive, bare for
>> lirens skyld.

Det ikke bare _ser ud_ som om - der _er nemt_.

> Javascript er ikke min stærke side, så indtil videre lever jeg bare med
> en masse inline-js-kald, selvom det giver en masse frygteligt
> uoverskuelig kode.

Du kunne smide et par links[1] med hvor du skal bruge det, så kan vi hurtigt
få dig op i omdrejninger ;)

Jeg bruger en del javascript i mit Notes system, og du kan evt. lure noget
kode her:
<http://w-o-p-r.dk/notes/show.base.asp?d=hjemmesideskolen_php>

Men det er ikke altid jeg laver det unobtrusive, for når jeg laver tingene,
er det lettere lige at lave 'onclick' m.m. i html'et.

Ajax bruger jeg til 'Quickview' funktionen (ikonet med
forstørrelsesglasset), hvor der også er noget klik og key event på
(esc=luk).

Det kunne være jeg skulle tjekke om der stadig ligger JS i HTML'et, og evt.
få det fjernet, så indtil videre er der ingen garanti for det er _helt_
unobtrusive.

Men ellers finder vi bare nogle andre eksempler.

[1] Skal nok være i .clientside gruppen.

--
Med venlig hilsen
Stig Johansen

---

Philip Nunnegaard sendte dette med sin computer:
> Rune Jensen skrev:
>
>> Er det så AAAX?
>>
>> Eller måske nærmere AAAH.. for det er ikke XML.
>
> Jeg tror egentlig at det jeg bruger, er noget som kaldes AHAH (Asychronous
> HTML and HTTP), men i daglig tale kalder jeg det bare "AJAX".
> Jeg trigger en php-fil via et javascript, og denne php-fil sender et output
> tilbage til en bestemt id på siden (f.eks. en <div>).
>
> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt på
> hvor jeg bruger det.

^^
Sikken masse flotte bogastavkombinationer - for ikke at tale om hvad
man kan få dem til at betyde.
IMHO, er det udemærket at kalde det AJAX, hvis man bruger
XMLHTTPRequest objectet. Men mere som en konvention end som en
betegnelse for hvad det egentlig kan bruges til.

Brug $_SESSION til at begrænse adgangen til scripts.
Ikke at den ikke kan omgås, men der skal lidt mere til, end bare at
kalde dit script..

Birger

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

---

Birger Sørensen skrev:

> Brug $_SESSION til at begrænse adgangen til scripts.
> Ikke at den ikke kan omgås, men der skal lidt mere til, end bare at
> kalde dit script..

Jeg bruger bare test af gzip, og smider dem væk (response.end), som ikke
forstår det.

Men at sætte og teste for en form for cookie tager nok også en del.

Jeg bruger det mest, hvor der er egentlig bruger-interaktion, dvs. når
brugeren kan skrive og sende noget tekst. Men derfor skal man
selvfølgelig validere på inputs alligevel.


MVH
Rune Jensen

---

Rune Jensen kom med følgende:
> Birger Sørensen skrev:
>
>> Brug $_SESSION til at begrænse adgangen til scripts.
>> Ikke at den ikke kan omgås, men der skal lidt mere til, end bare at kalde
>> dit script..
>
> Jeg bruger bare test af gzip, og smider dem væk (response.end), som ikke
> forstår det.
>
> Men at sætte og teste for en form for cookie tager nok også en del.
>
> Jeg bruger det mest, hvor der er egentlig bruger-interaktion, dvs. når
> brugeren kan skrive og sende noget tekst. Men derfor skal man selvfølgelig
> validere på inputs alligevel.
>
>
> MVH
> Rune Jensen

$_SESSION sætter og tester data serverside. Ikke clientside.
Der er selvfølgelig en cookie med sessionid involveret, men den
indeholder ikke de data der bliver testet serverside.

I det script der f.eks. sender en HTML-form til brugeren, tilføjes
f.eks. $_SESSION[ 'form'] = "Vist";
Det script der modtager data fra formen, kan så teste

if ( $_SESSION[ 'form'] != "Vist") {
echo "Intruder alert!";
}
else {
// check af valide data fra formen, og yderligere data behandling
}
$_SESSION[ 'form'] = "";

Ud over at finde på en måde at sætte $_SESSION på, skal en misbruger
desuden gætte at variablen hedder 'form' i arrayet, og værdien skal
være "Vist", for at data accepteres.
Det fungerer fint på varmerettte.dk.

Birger

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

---

Birger Sørensen skrev:

> if ( $_SESSION[ 'form'] != "Vist") {
> echo "Intruder alert!";
> }
> else {
> // check af valide data fra formen, og yderligere data behandling
> }
> $_SESSION[ 'form'] = "";
>
> Ud over at finde på en måde at sætte $_SESSION på, skal en misbruger
> desuden gætte at variablen hedder 'form' i arrayet, og værdien skal være
> "Vist", for at data accepteres.
> Det fungerer fint på varmerettte.dk.

Det ligner mest en CAPCHA af den slags hvor man ikke generer brugeren
med at skulle indtaste noget ekstra.

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

---

"Birger Sørensen" <sdc@bbsorensen.com> wrote in message
news:4b36a8df$0$278$14726298@news.sunsite.dk...
>
> I det script der f.eks. sender en HTML-form til brugeren, tilføjes
> f.eks. $_SESSION[ 'form'] = "Vist";
> Det script der modtager data fra formen, kan så teste
>
> if ( $_SESSION[ 'form'] != "Vist") {
> echo "Intruder alert!";
> }
> else {
> // check af valide data fra formen, og yderligere data behandling
> }
> $_SESSION[ 'form'] = "";

Her skal du være opmærksom på, at PHP (og ASP) sender cookie informationer
med sammen med HTML'et.

Hvis det virker, så virker det, men det er ingen kunst for bot'er at tage
Set-cookie: headeren fra GET requesten, og medsende den som Cookie: i POST
requesten.

Jeg har lavet det så 'logoet' bliver kaldt med:
http://w-o-p-r.dk/images/picture.asp?name=wopr2.gif

I picture.asp sætter jeg så:
Session("IP") = Request.Servervariables("REMOTE_ADDR")

Og i f.eks. en login funktion:
.....
if Session("IP") <> Request.Servervariables("REMOTE_ADDR") then
Response.Write "Cookies disabled, or a bot"
Response.End
end if
.....

På den måde skelner jeg mellem programmer, der ikke kun læser HTML'et, men
parser den og henter <img>.

Ved at bruge IP adressen sikrer jeg mig også, at det er samme IP adresse der
har hentet den.

Det er sikkert ikke så sandsynligt af bot'erne udveksler cookie data, men
det er 100% sikkert de 'snakker' sammen.

For - ja nok snart et par år siden - havde vi (Rune og jeg) nogle
eksperimenter kørende.

Et af dem gik ud på at sende en positiv response på namogofer proben, så de
troede der var 'bid'.

Der gik ikke mange timer før vi blev 'voldrequestet' med Phase II fra
forskellige IP adresser, og samtidig ophørte Phase I proves.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen forklarede:
> "Birger Sørensen" <sdc@bbsorensen.com> wrote in message
> news:4b36a8df$0$278$14726298@news.sunsite.dk...
>>
>> I det script der f.eks. sender en HTML-form til brugeren, tilføjes
>> f.eks. $_SESSION[ 'form'] = "Vist";
>> Det script der modtager data fra formen, kan så teste
>>
>> if ( $_SESSION[ 'form'] != "Vist") {
>> echo "Intruder alert!";
>> }
>> else {
>> // check af valide data fra formen, og yderligere data behandling
>> }
>> $_SESSION[ 'form'] = "";
>
> Her skal du være opmærksom på, at PHP (og ASP) sender cookie informationer
> med sammen med HTML'et.
>
> Hvis det virker, så virker det, men det er ingen kunst for bot'er at tage
> Set-cookie: headeren fra GET requesten, og medsende den som Cookie: i POST
> requesten.
>
> Jeg har lavet det så 'logoet' bliver kaldt med:
> http://w-o-p-r.dk/images/picture.asp?name=wopr2.gif
>
> I picture.asp sætter jeg så:
> Session("IP") = Request.Servervariables("REMOTE_ADDR")
>
> Og i f.eks. en login funktion:
> ....
> if Session("IP") <> Request.Servervariables("REMOTE_ADDR") then
> Response.Write "Cookies disabled, or a bot"
> Response.End
> end if
> ....
>
> På den måde skelner jeg mellem programmer, der ikke kun læser HTML'et, men
> parser den og henter <img>.
>
> Ved at bruge IP adressen sikrer jeg mig også, at det er samme IP adresse der
> har hentet den.
>
> Det er sikkert ikke så sandsynligt af bot'erne udveksler cookie data, men
> det er 100% sikkert de 'snakker' sammen.
>
> For - ja nok snart et par år siden - havde vi (Rune og jeg) nogle
> eksperimenter kørende.
>
> Et af dem gik ud på at sende en positiv response på namogofer proben, så de
> troede der var 'bid'.
>
> Der gik ikke mange timer før vi blev 'voldrequestet' med Phase II fra
> forskellige IP adresser, og samtidig ophørte Phase I proves.

Smart nok.
Men IP adresser kan omgås - eller flere kan bruge den samme.

På min måde, skal bot'erne, stadig gætte varibalnavn og indhold, og
finde en metode til at sætte den, for at data bliver modtaget.
Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
en SESSION ikke er sikre - at der er måder at omgå sessionid på, f.eks.
ved at "lytte" på kommunikation mellem andre - men ikke om det kan lade
sig gøre, faktisk at ændre indholdet af en SESSION.
Og selv om sessionid kendes, skal der stadig sættes en ukendt variabel
til en ukendt værdi.

Birger

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

---

Birger Sørensen wrote:

> Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
> en SESSION ikke er sikre - at der er måder at omgå sessionid på, f.eks.
> ved at "lytte" på kommunikation mellem andre

"lytte" kan man nok ikke - med mindre man har adgang til ISP'ernes udstyr.
Jeg ved ikke hvad de skriver, men det er muligt at lave session hijacking
vha. XSS (cross site scripting).

Det gå ud på at aflæse (session) cookies, så man derved kan benytte cookies,
samt igangværende sessions.

Igangværende sessions er nok ikke så sandsynligt, da det kræver nærmest real
time overvågning, men der er mange systemer, der har en 'husk mig' cookies,
og logger automatisk på.

Ved at overtage disse, kan serveren ikke se forskel på den rigtige person og
den kriminelle, og man har dermed 'fri adgang' til siden.

> - men ikke om det kan lade
> sig gøre, faktisk at ændre indholdet af en SESSION.
> Og selv om sessionid kendes, skal der stadig sættes en ukendt variabel
> til en ukendt værdi.

Jeg er lidt i tvivil om vi snakker om det samme.
I ASP er en session alene identificeret ved en session cookie med en
ASPSESSIDXYZQ=<noget.unikt>

Alt session _data_ ligger på serveren, og bliver behandlet på serveren, ud
fra brugerens(eller bot'ens) handlinger.

Så i ASP regi vil en GET medføre at data bliver sat i forhold til requesten,
og i den efterfølgende POST vil disse data optræde, uanset om det er en
browser eller bot, der har udført requesten.

Jeg sætter ikke nogle felter clientside, som der skal 'gættes'.

--
Med venlig hilsen
Stig Johansen

---

Efter mange tanker skrev Stig Johansen:
> Birger Sørensen wrote:
>
>> Jeg ved ikke om det overhovedet er muligt. php.net siger kun at data i
>> en SESSION ikke er sikre - at der er måder at omgå sessionid på, f.eks.
>> ved at "lytte" på kommunikation mellem andre
>
> "lytte" kan man nok ikke - med mindre man har adgang til ISP'ernes udstyr.
> Jeg ved ikke hvad de skriver, men det er muligt at lave session hijacking
> vha. XSS (cross site scripting).
>
> Det gå ud på at aflæse (session) cookies, så man derved kan benytte cookies,
> samt igangværende sessions.
>
> Igangværende sessions er nok ikke så sandsynligt, da det kræver nærmest real
> time overvågning, men der er mange systemer, der har en 'husk mig' cookies,
> og logger automatisk på.
>
> Ved at overtage disse, kan serveren ikke se forskel på den rigtige person og
> den kriminelle, og man har dermed 'fri adgang' til siden.
>
>> - men ikke om det kan lade
>> sig gøre, faktisk at ændre indholdet af en SESSION.
>> Og selv om sessionid kendes, skal der stadig sættes en ukendt variabel
>> til en ukendt værdi.
>
> Jeg er lidt i tvivil om vi snakker om det samme.
> I ASP er en session alene identificeret ved en session cookie med en
> ASPSESSIDXYZQ=<noget.unikt>
>
> Alt session _data_ ligger på serveren, og bliver behandlet på serveren, ud
> fra brugerens(eller bot'ens) handlinger.
>
> Så i ASP regi vil en GET medføre at data bliver sat i forhold til requesten,
> og i den efterfølgende POST vil disse data optræde, uanset om det er en
> browser eller bot, der har udført requesten.
>
> Jeg sætter ikke nogle felter clientside, som der skal 'gættes'.

Ud over session-cookien, sætter jeg heller ikke noget clientside.
Men det gør jeg serverside.
For at data fra en form accepteres, skal en given værdi i SESSION være
rigtig. Værdien sættes, når den besøgende henter formen, og slettes
igen, når den submittes.
En bot kan altså ikke bare kalde scriptet der indsender data - formen
_skal_ være vist (hentet, i hvert fald) for den samme SESSION, een gang
for hver submit.

Som Phillip skriver, fungerer det som en slags CAPCHA - bare uden at
genere brugeren, og ved at bruge samme værdi hver gang (men kunne godt
udbygges til at være en tilfældig værdi).
For at omgå det, skal man have adgang til at ændre session-data,
hvilket vil kræve scripts på serveren der hoster sitet - men er der
adgang til dét, kan alle forholdsregler vist omgås, og der vil være
alvorligere sikkerhedsbrud der nok skal prioriteres højere...

Birger

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

---

Birger Sørensen skrev:

>> Jeg sætter ikke nogle felter clientside, som der skal 'gættes'.
>
> Ud over session-cookien, sætter jeg heller ikke noget clientside.
> Men det gør jeg serverside.

Man kan lave et fingerprint (en slags GUID) sat sammen af f.eks. user
agent, IP og accept-language. Det kan f.eks. være at tage alle tal eller
ASC-værdier i user agent, IP og accept-language, lægge dem sammen og
ANDe med en værdi a la 2^n-1, lægge disse tal sammen og igen ANDe. På
den måde får man en nogenlunde unik værdi for lige dén bruger.

Fingerprintet kan bruges direkte, hvor de skal være ens imellem GET og
POST, og/eller man kan sætte det sammen og lave en variabel stardate. så
man samtidig tjekker for, om det er POSTet for kort/lang tid efter GET.
Denne stardate vil være afhængig (til en vis grad) af brugerens
browser/IP. Det smarte her er, at man kun sender resultatet, selve
formlen og udregningen af værdien er skjult for brugeren.

En anden måde at lave finger print på, er at se på, hvordan hver browser
identificerer sig generelt, men også i forhold til andre (særlige
kendetegn):

http://www.computec.ch/projekte/browserrecon/?

Her kan man se forskellene i de enkelte browsere, bl.a. at IE altid
sætter et mellemrum imellem en liste (f.eks. gzip, deflate - altså gzip
mellemrum deflate).

Jeg har også fundet denne side, som beskæftiger sig med, hvad browserne
understøtter:

http://www.browserscope.org/

Jeg synes dog problemet her er, man kan ikke være sikker på, hvordan
browserne vil opføre sig i fremtiden, så jeg bruger selv førstnævnte
generiske metode i stedet.

Jeg har lavet en fixed-lenght fingerprint-funktion her, nederst på siden:

http://runejensen.dk/om/testside.asp

Hvis man tjekker efter, kan man godt se, det er ens for samme
browser/IP, men skifter browseren eller IPen, skifter IDet også.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg har lavet en fixed-lenght fingerprint-funktion her, nederst på siden:
>
> http://runejensen.dk/om/testside.asp
>
> Hvis man tjekker efter, kan man godt se, det er ens for samme
> browser/IP, men skifter browseren eller IPen, skifter IDet også.

En variabel stardate ville her kunne laves ved at trimme 0'er væk,
trække hvert enkelt ciffer ud, lægge det sammen med forrige, derefter
ANDe med 31. Dette kan man bruge som udgangspunkt i stardaten GET=tiden
i skunder fra 1971+[tal] og POST=tiden i sekunder fra 1971+[tal].
Trækker man GETtid fra POSTtid (da POST nødvendigvis må foregå efter
GET), har man tiden, der er gået imellem.

Herefter vil bare en forskel på én i [tal] betyde en forskel på ét år.
Det er næppe sandsynligt, man vil være et år (eller mere) om at POSTe.


MVH
Rune Jensen

---

Rune Jensen tastede følgende:
> Birger Sørensen skrev:
>
>>> Jeg sætter ikke nogle felter clientside, som der skal 'gættes'.
>>
>> Ud over session-cookien, sætter jeg heller ikke noget clientside.
>> Men det gør jeg serverside.
>
> Man kan lave et fingerprint (en slags GUID) sat sammen af f.eks. user agent,
> IP og accept-language. Det kan f.eks. være at tage alle tal eller ASC-værdier
> i user agent, IP og accept-language, lægge dem sammen og ANDe med en værdi a
> la 2^n-1, lægge disse tal sammen og igen ANDe. På den måde får man en
> nogenlunde unik værdi for lige dén bruger.
>
> Fingerprintet kan bruges direkte, hvor de skal være ens imellem GET og POST,
> og/eller man kan sætte det sammen og lave en variabel stardate. så man
> samtidig tjekker for, om det er POSTet for kort/lang tid efter GET. Denne
> stardate vil være afhængig (til en vis grad) af brugerens browser/IP. Det
> smarte her er, at man kun sender resultatet, selve formlen og udregningen af
> værdien er skjult for brugeren.
>
> En anden måde at lave finger print på, er at se på, hvordan hver browser
> identificerer sig generelt, men også i forhold til andre (særlige kendetegn):
>
> http://www.computec.ch/projekte/browserrecon/?
>
> Her kan man se forskellene i de enkelte browsere, bl.a. at IE altid sætter et
> mellemrum imellem en liste (f.eks. gzip, deflate - altså gzip mellemrum
> deflate).
>
> Jeg har også fundet denne side, som beskæftiger sig med, hvad browserne
> understøtter:
>
> http://www.browserscope.org/
>
> Jeg synes dog problemet her er, man kan ikke være sikker på, hvordan
> browserne vil opføre sig i fremtiden, så jeg bruger selv førstnævnte
> generiske metode i stedet.
>
> Jeg har lavet en fixed-lenght fingerprint-funktion her, nederst på siden:
>
> http://runejensen.dk/om/testside.asp
>
> Hvis man tjekker efter, kan man godt se, det er ens for samme browser/IP, men
> skifter browseren eller IPen, skifter IDet også.
>
>
> MVH
> Rune Jensen


Tidsmaskine?

Det startede sådan set med et lille fif til Philip om en simpel måde at
forhindre scripts i at blive misbrugt af de mest indlysende misbrugere.
Det simple er gået lidt af, syntes jeg.

En SESSION udløber af sig selv, efter et givet stykke tid, så at checke
på tid er ikke nødvendigt (og en almindelig besøgende skal jo også have
en chance for faktisk at bruge tingene som de er beregnet).

Der sendes ikke noget frem og tilbage - ikke engeng resultatet. Det
hele forgår på serveren. Bortset fra sessionid, som i forvejen
eksisterer, er unikt - at genererer (endnu) et "fingerprint" er IMHO
ikke nødvendigt. Sessionid bruges til identifikation, og det er enkelt
og overskueligt at programmere.

Der checkes godt nok ikke for IP'er, og jeg er ikke sikker på at det er
en god idé.
http://dk.php.net/manual/en/session.security.php
"In addition to ip-address binding not always being effective, it can
also prevent users connecting through a proxy-pool from even being able
to use your site. In such a scenario, a person's IP address may very
well change with every access."
Men ønsker man det, kan man jo sætte den værdi der skal checkes for,
til at være den aktuelle IP:

I det script der f.eks. sender en HTML-form til brugeren, tilføjes
f.eks. $_SESSION[ 'form'] = getenv( 'REMOTE_ADDR');
Det script der modtager data fra formen, kan så teste

if ( $_SESSION[ 'form'] != getenv( 'REMOTE_ADDR')) {
echo "Intruder alert!";
}
else {
// check af valide data fra formen, og yderligere data behandling
}
$_SESSION[ 'form'] = "";

Der accepteres kun data fra fra samme IP, og kun hvis formen er blevet
vist (hentet) i samme SESSION.

En bot - eller andre, hvis hensigt er at genere - kan altså ikke bare
sende data i et væk til scriptet der modtager data. Jeg tror det er den
slags, Philip er nervøs for.

Og selvfølgelig kan det omgås hvis man er ihærdig nok. Det er der vist
ikke noget der ikke kan.

Birger

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

---

Birger Sørensen skrev:

> En SESSION udløber af sig selv, efter et givet stykke tid, så at checke
> på tid er ikke nødvendigt (og en almindelig besøgende skal jo også have
> en chance for faktisk at bruge tingene som de er beregnet).

Idéen er, man kan næppe POSTe indenfor et par sewkunder efter GET, hvis
man er "human". Det er det, man bruger stardate til at tjekke for (i
denne forbindelse).

En sådan post, vil med garanti ikke være interessant heller. Mennesker
skal bruge tid på at skrive noget, andre synes er interessant. BOTter
har travlt, de bruger næppe mere end et par sekunder til hver post.

Session kræver vel en cookie, ellers kan jeg slet ikke se, hvordan du
kan identificere en bruger, hvilket vil sige, man kan ikke bruge din idé
uden cookies slået til. Idéen med GUID kan bruges af alle medier, som
forstår HTML. Og om det sendes som GUID med formen som hidden field
eller egentlig cookie kan vel komme ud på ét hvad angår hastighed (hvis
man skal se sådan på det).

At danne stardate udfra en GUID, er smart i og med, man ikke kan spoofe
den uden at kende formlen. Man kan lave brute-force-angreb eller
dictionary-attacks, men de vil blve opdaget, fordi de nødvendigvis vil
betyde en masse gentagne næsten ens forsøg, og kan blokeres.

IP... det er korrekt, det kan skabe problemer at IPer skifter. Den
oprindelige idé indeholder heller ikke IP, det er noget, jeg har
tilføjet. Det er ikke mig, som har fundet på fingerprint, det er gammel
viden, for så vidt.


MVH
Rune Jensen

---

Rune Jensen tastede følgende:
> Birger Sørensen skrev:
>
>> En SESSION udløber af sig selv, efter et givet stykke tid, så at checke på
>> tid er ikke nødvendigt (og en almindelig besøgende skal jo også have en
>> chance for faktisk at bruge tingene som de er beregnet).
>
> Idéen er, man kan næppe POSTe indenfor et par sewkunder efter GET, hvis man
> er "human". Det er det, man bruger stardate til at tjekke for (i denne
> forbindelse).
>
> En sådan post, vil med garanti ikke være interessant heller. Mennesker skal
> bruge tid på at skrive noget, andre synes er interessant. BOTter har travlt,
> de bruger næppe mere end et par sekunder til hver post.
>
> Session kræver vel en cookie, ellers kan jeg slet ikke se, hvordan du kan
> identificere en bruger, hvilket vil sige, man kan ikke bruge din idé uden
> cookies slået til. Idéen med GUID kan bruges af alle medier, som forstår
> HTML. Og om det sendes som GUID med formen som hidden field eller egentlig
> cookie kan vel komme ud på ét hvad angår hastighed (hvis man skal se sådan på
> det).
>
> At danne stardate udfra en GUID, er smart i og med, man ikke kan spoofe den
> uden at kende formlen. Man kan lave brute-force-angreb eller
> dictionary-attacks, men de vil blve opdaget, fordi de nødvendigvis vil betyde
> en masse gentagne næsten ens forsøg, og kan blokeres.
>
> IP... det er korrekt, det kan skabe problemer at IPer skifter. Den
> oprindelige idé indeholder heller ikke IP, det er noget, jeg har tilføjet.
> Det er ikke mig, som har fundet på fingerprint, det er gammel viden, for så
> vidt.
>
>
> MVH
> Rune Jensen

Jeg har selv prøvet at være så længe om at udfylde en form, at man
bliver smidt af. P**** irriterende.
Når det sker, åbner jeg gerne min tekst editor og skriver teksten der
anden gang (faktisk også af og til, hvis jeg forventer det vil tage
lidt tid at skrive hvad jeg har på hjerte), hvorefter jeg går tilbage
til formen og paster teksten. Afhængig af formens øvrige indhold, kan
jeg altså godt udfylde og sende en form i løbet af "et par sekunder" -
også med relevant og interessant indhold.

SESSION virker også uden cookies. Hvis en cookie ikke kan sættes,
overføres id'et med URL'en.
http://dk2.php.net/manual/en/session.idpassing.php

Jeg sætter data i $_SESSION[] serverside, og sammenligner serverside.
De data der skal have bestemte værdier, eller værdierne selv er aldrig
clientside. Selv om man skulle være heldig at gætte både det rigtige
navn og den rigtige værdi (og at det er det der sker, i det hele
taget), kan man ikke sætte dem, uden først at kompromitere hotellets
skkerhed, fordi det kræver adgang til sessiondata på hotellet.

Hvis en bot vil misbruge min form, kan den sagtens det. Den skal bare
hente formen og indsende den, hver gang.
Det er der så andre måder at imødegå, som du siger - men så er vi ude
over det simple...
(Jeg registrer IP, finder ISP, og sender fremtidige "indlæg" fra IP'en
til ISP'en, i stedet for til mig selv - kræver lidt manuelt arbejde.
Som Stig var inde på, snakker bot'erne sammen, og der har da været
nogle forsøg, men de stoppede meget hurtigt, helt af sig selv.)

Birger

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

---

Birger Sørensen wrote:

> Jeg har selv prøvet at være så længe om at udfylde en form, at man
> bliver smidt af. P**** irriterende.

Vi (I) snakker forbi hinanden.
Der er ikke tale om at det tager for lang tid, men for kort tid.

Hvis en POST kommer nærmest inden for samme sekund, er det højst
usandsynligt at det er et menneske, da dette sekund også omhandler tid til
at vise formen, for slet ikke at tale om at udfylde den.

Google bruger vist noget med ca 10 sekunder, og på et eller andet tidspunkt
var der gået ged i min FF, så jeg fik en side fra Google a lá:

"You seem to be doing automatic requests - click here if you are a human
being" efterfulgt af et link med "Yes I am a human being".

Jeg ved ikke hvad der var sket med FF, men den loopede åbenbart, men en
genstart af FF løste det.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen udtrykte præcist:
> Birger Sørensen wrote:
>
>> Jeg har selv prøvet at være så længe om at udfylde en form, at man
>> bliver smidt af. P**** irriterende.
>
> Vi (I) snakker forbi hinanden.
> Der er ikke tale om at det tager for lang tid, men for kort tid.

Hvor lang tid tager det at hente en form, paste en tekst og indsende
den?
Jeg vil godt påtage mig at gøre det på under de 20 sekunder, i siger
nogle bot'er venter...

> Hvis en POST kommer nærmest inden for samme sekund, er det højst
> usandsynligt at det er et menneske, da dette sekund også omhandler tid til
> at vise formen, for slet ikke at tale om at udfylde den.

Et tidsstempel, kan da sikkert fange nogle af dem. Er det besværet og
resourcerne værd?

> Google bruger vist noget med ca 10 sekunder, og på et eller andet tidspunkt
> var der gået ged i min FF, så jeg fik en side fra Google a lá:
>
> "You seem to be doing automatic requests - click here if you are a human
> being" efterfulgt af et link med "Yes I am a human being".
>
> Jeg ved ikke hvad der var sket med FF, men den loopede åbenbart, men en
> genstart af FF løste det.

Det går ikke altid som præsten spår - og ind imellem går det helt galt


Birger

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

---

Birger Sørensen skrev:

> Hvor lang tid tager det at hente en form, paste en tekst og indsende den?
> Jeg vil godt påtage mig at gøre det på under de 20 sekunder, i siger
> nogle bot'er venter...

Ikke 20 sekunder. Nærmere 5. Og du vil ikke behøve at skulle copy/paste,
hvis ikke der opstår problemer. Det er et spørgsmål om, at siden tager
højde for fejlmeldinger til brugeren, og har mere med brugervenlighed at
gøre.

De absolut _eneste_ copy/pastede forsøg, jeg har haft fra humans var
reklamer for kondomer og et eller andet investment. Det er fordi de har
det liggende i clipbordet, så kan de spamme en 15-20 ad gangen meget
hurtigt (danskere har nok ikke råd til egne botter).

Sådanne forsøg oplever man kun pt. i DK fra wannabee SEOer. Altså rene
amatører. De bruger Google (eller i sjældne tilfælde et
Google-specialiceret værktøj) til at finde sider, som har en form med
mulighed for at lave indlæg, og hvor der ikke bruges rel="nofollow".

> Et tidsstempel, kan da sikkert fange nogle af dem. Er det besværet og
> resourcerne værd?

Det kommer an på... jeg har haft to succesfulde angreb indtil nu. Ved
noget, man vel kan kalde dictionary attack. Lignede fuldstændigt
mennesker, nok fordi det VAR mennesker. Ukrainsk/Israelsk IP, så der
sidder nogle studerende med en Google Translate, som får nogle håndører
for hver meddelelse de får igennem. Kan ikke huske indhædet, men mange
bruger en ID-streng først i meddelelsen. Så den kan findes på google,
formoder jeg.

Din side vil først blive rigtigt angrebet på den måde, når du kommer op
i en vis højde i søgemaskinerne, for ellers er det ikke pengene værd. Så
gør man det automatisk i stedet. En anden ting er selvfølgelig, hvis din
sides "fingeraftryk", opsætning, filnavne, form-/feltnanvne minder om
noget generelt og populært, f.eks. WordPress. Så skal du se løjer. Der
er en eller anden sammenhæng imellem investering af tid/penge kontra
lethed hvormed koderne/CAPTCHA/IDer osv. brydes kontra hvad man får ud
af det i sidste ende.

>> Google bruger vist noget med ca 10 sekunder, og på et eller andet
>> tidspunkt
>> var der gået ged i min FF, så jeg fik en side fra Google a lá:
>>
>> "You seem to be doing automatic requests - click here if you are a human
>> being" efterfulgt af et link med "Yes I am a human being".
>>
>> Jeg ved ikke hvad der var sket med FF, men den loopede åbenbart, men en
>> genstart af FF løste det.
>
> Det går ikke altid som præsten spår - og ind imellem går det helt galt

Det var et forsøg fra Google, og jeg har oplevet det i anden
forbindelse, hvor den konstant fortalte, jeg lavede "ulovlige
søgninger", jvfr. det første svar. Den del har de formodentlig optimeret
nu, for jeg har siden lavet samme eller mere mistænkelige søgninger uden
problemer. Måske tjekker de min IP imod en DB ;)


MVH
Rune Jensen

---

Rune Jensen sendte dette med sin computer:
> Birger Sørensen skrev:
>
>> Hvor lang tid tager det at hente en form, paste en tekst og indsende den?
>> Jeg vil godt påtage mig at gøre det på under de 20 sekunder, i siger nogle
>> bot'er venter...
>
> Ikke 20 sekunder. Nærmere 5. Og du vil ikke behøve at skulle copy/paste, hvis
> ikke der opstår problemer. Det er et spørgsmål om, at siden tager højde for
> fejlmeldinger til brugeren, og har mere med brugervenlighed at gøre.
>
> De absolut _eneste_ copy/pastede forsøg, jeg har haft fra humans var reklamer
> for kondomer og et eller andet investment. Det er fordi de har det liggende i
> clipbordet, så kan de spamme en 15-20 ad gangen meget hurtigt (danskere har
> nok ikke råd til egne botter).
>
> Sådanne forsøg oplever man kun pt. i DK fra wannabee SEOer. Altså rene
> amatører. De bruger Google (eller i sjældne tilfælde et Google-specialiceret
> værktøj) til at finde sider, som har en form med mulighed for at lave indlæg,
> og hvor der ikke bruges rel="nofollow".

Prøver lige igen :
"Jeg har selv prøvet at være så længe om at udfylde en form, at man
bliver smidt af. ...
.... åbner jeg gerne min tekst editor og skriver teksten der anden gang
.... hvorefter jeg går tilbage til formen og paster teksten. Afhængig af
formens øvrige indhold, kan jeg altså godt udfylde og sende en form i
løbet af "et par sekunder" - også med relevant og interessant indhold."

Dit system skal altså kunne se forskel på om der hældes acceptabelt
indhold på, eller skrammel.. For fremgangsmåden er den samme, og kan
vel så forventes at tage nogenlunde lige lang tid?

8X
> Din side vil først blive rigtigt angrebet på den måde, når du kommer op i en
> vis højde i søgemaskinerne, for ellers er det ikke pengene værd. Så gør man
> det automatisk i stedet.
8X

Prøv - bare for sjov - at søg på varme retter på google, og fortæl mig
hvor meget højere siden skal op, før jeg kan forvente det?

Birger

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

---

Birger Sørensen skrev:

> Dit system skal altså kunne se forskel på om der hældes acceptabelt
> indhold på, eller skrammel.. For fremgangsmåden er den samme, og kan vel
> så forventes at tage nogenlunde lige lang tid?

Jomen... hvorfor skulle du copy/paste nogetsomhelst, hvis mit system
poster som det skal? Dit udgangspunkt er jo, at det går ned, og det er
derfor, du vil copy/paste.

Mit udgangspunkt med at være for lang tid om det gælder et år eller mere
udfra variabel stardate. Eller at POSTe et år eller mere INDEN, man
GETer siden (POST stardate 1 år ældre end GET). Hvornår har nogen været
så lang tid om at besvare eller kunne rejse i tid? ;)

Men OK.

Lad os sige, du GETter. Forsøger at POSTe - det giver en fejl.

OK, her går du ind og skriver i din Word eller lign. I mellemtiden, så
tæller tiden jo, for initial stardate ligger i selve sidens form som
hidden field. Så når du har skrevet dit indlæg og copy/paster, derefter
POSTer, vil du ALLIGEVEL have brugt mere end de 5 sekunder. Her er det
applikationen, som skal give en meddelelse om, at noget gik galt, og du
må forsøge igen. Jeg vil mene, det er et brugervenlighedsspørgsmål i
fbm. error-handling mere end det har med sikkerhed/spam og denne
stardate-check at gøre. F.eks. at man ikke "husker", hvad der blev
skrevet ved fejl, men bare resetter formen. Så er det klart, man
overvejer en copy/paste i stedet.

Men igen - hvis nu systemet virker, formen er fejlfri, ingen problemer
med at skrive eller poste, hvad skulle hele idéen så være i, først at
åbne Word, dernæst skrive og så copy/paste, når der er en fuldt virkende
form til det samme på hjemmesiden?

Har du nogensinde haft brug for at skulle copy/paste, når systemet så
virker - og hvorfor?

Læg iøvrigt mærke til, hvad Stig skriver: Det er tiden imellem GET og
POST, og heri iregnes også den tid det tager at sende siden og tegne den
op. Så det er mere, end man umiddelbart tror. Jeg tvivler nu lidt på, du
kan gøre det med en forskel på 5 sekunder.

Men jeg vil gerne flikke en test sammen, hvis det er, jeg er næsten også
nødt til at lave et proof-of-concept, så kan man én gang for alle få at
se, hvor hurtigt det kan gøres, og hvad en stardate vil betyde. I så
fald laver jeg lige nyt indlæg ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jomen... hvorfor skulle du copy/paste nogetsomhelst, hvis mit system
> poster som det skal? Dit udgangspunkt er jo, at det går ned, og det er
> derfor, du vil copy/paste.

Har du aldrig prøvet at være logget ind på et webforum eller et andet
sted og så oplevet at du var smidt af, inden du fik skrevet færdig og
submittet det hele?

15-20 minutter er rigeligt. (Mener at IIS som standard dræber en session
efter 20 minutters inaktivitet - det er sikkert det samme på andre
systemer).

Man kan komme med lange foredrag om at siden så er lavet forkert, eller
at systemet er sat forkert op, men det kan brugeren jo ikke gøre en skid
ved. Han vælger bare at tage udgangspunkt i at *alle* systemer er sådan
eller kan opføre sig sådan, og forholdsreglen er så at skrive en kladde
på forhånd.

Jeg kender flere der skriver en kladde i et tekstbehandlingsprogram
(f.eks. Notepad/Wordpad) for så at kopiere det hele over.

ComX' webmail er et eksempel på en side der er virkelig slem på det
område. Hele mails går tabt på den konto.

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

---

Birger Sørensen skrev:

> Prøv - bare for sjov - at søg på varme retter på google, og fortæl mig
> hvor meget højere siden skal op, før jeg kan forvente det?

Hvis du er eksponeret nok, men stadig ikke mener, du får din retmæssige
portion af spambotter, injectors, harvesters osv. så er det nok pga. din
hjemmeside ikke tricker. Det kan være emnet, eller det kan være
filnavne/feltnavne mv. som ikke dukker op på deres søgninger i Google.
Min har en side med et filnavn: links.asp, og det gav i dén grad
besøgende, så et eller andet sted er der måske en OS script, som også
bruger det filanvn, og som er åbent som en ladeport. Det kan
selvfølgelig også være form-felters navne i sig selv, som er med til
det. Men jeg har helt suverænt været spammet mest på den side.

Og så en sjov ting... begge succesfulde attempts, altså hvor spammerne
fik et indlæg igennem sikkerheden (skriv tallet fire), gik igennem en
side med filnavn comment_script.asp

Gæt selv, om den er interessant? Og hvorfor den blev fundet?

Hvor tæt ligger "varme retter" i forhold til på en intersaant søgning på
Google for form spam?

Spammere søger vel ikke på samme måde som mennesker, de er jo
interesseret i forskellige ting. Nærmere søger de på noget a la
"guestbook -nofollow" eller "leave a comment -nofollow"

I denne forbindelse er det ikke danskere, men nogle, som bliver betalt
for det i Ukraine eller Rusland, og de søger - tor jeg - på engelske
ord, og/eller efter en ordbog for forskellige lande over bestemte ord,
som "tricker". Siden hedder "kommentar-script", det kan nemt oversættes
til comment-script.

Apropos, Google-søgning, prøv disse (fjern mellemrum):

http://www.google
..dk/#hl=da&q=kommentar+form&meta=&aq=&oq=kommentar+form&fp=73be2594e4cbf730

http://www.google
..dk/#hl=da&q=g%C3%A6stebog+form&meta=&aq=&oq=g%C3%A6stebog+form&fp=73be2594e4cbf730


MVH
Rune Jensen

---

"Rune Jensen" <runeofdenmark@gmail.com> wrote in message
news:4b37e8f4$0$4814$456a7185@news.cirque.dk...
> Min har en side med et filnavn: links.asp, og det gav i dén grad
> besøgende, så et eller andet sted er der måske en OS script, som også
> bruger det filanvn, og som er åbent som en ladeport.

En side, der hedder links, er jo et åbenlyst target for folk, der ønsker at
poste links, så der er vist ingen tvivl der, for alene navnet indikerer en
mulighed.

> Det kan
> selvfølgelig også være form-felters navne i sig selv, som er med til
> det.

Jeg er sikker på feltnavnene også spiller ind, for de har formentlig en
begrænset ordliste, evt med soundex.

Og her brugte du:
Name,Homepage,Message smt at formen havde en id="comments-form"

> Gæt selv, om den er interessant? Og hvorfor den blev fundet?

Jeg behøver ikke at gætte ;)

> Hvor tæt ligger "varme retter" i forhold til på en intersaant søgning på
> Google for form spam?

Nu skulle det nødigt udvikle sig til en 'konkurrence' om hvem der får mest
spam, men der er også det med feltnavnene.

Formålet med disse blog/comment spam er jo at få lagt en masse links ind,
enten til 'almindelige' reklamer, eller deciderede malware sider.

Derfor giver det mening kun at forsøge at POST'e der hvor det giver mening.
Birger bruger f_msg som feltnavn, som med god vilje kan fortolkes som et
message felt (msg), men det er ikke så åbenlyst.

Selvom bot'erne principielt har 'tid nok' forlyder det også at priserne for
inficering/spam falder pga. den stigende konkurrence, så selv 'de' bliver
nødt til at optimere deres systemer.

--
Med venlig hilsen/Best regards
Stig Johansen

---

Stig Johansen skrev:
> "Rune Jensen" <runeofdenmark@gmail.com> wrote in message
> news:4b37e8f4$0$4814$456a7185@news.cirque.dk...

>> Det kan
>> selvfølgelig også være form-felters navne i sig selv, som er med til
>> det.
>
> Jeg er sikker på feltnavnene også spiller ind, for de har formentlig en
> begrænset ordliste, evt med soundex.

Det er det, jeg mener, botterne eller spammerne skal jo først finde
siden, før de kan finde ud af, om den har interessante spamfelter.

Det er nu heller ikke så svært at tilrette sin søgning med Google - mon
folk ved, HVOR mange ting, man kan finde med den søgemaskine, som folk
tror, de har for sig selv?

allinurl:XYZ - XYZ indgår i URLen (bruges beviseligt af ondsindede
hackere - mere kraftfuld, end man tror)

allintitle:XYZ - XYZ indgår i sidens <title>

allintext:XYZ - XYZ indgår i brødteksten

filetype:XYZ - XYZ er filtypen

-XYZ søger efter en side, som IKKE indeholder strengen XYZ

Og der er flere, hvis man tænker sig om, som kan bruges i ondsindet
øjemed. Der dukker jævnligt artikler op på nettet om at dette eller hint
firma har været "uheldige", og har fået indekseret f.eks. useraccounts
af Google. Så det er bare med at være varsom og strict med, hvad man
linker til i sit sitemap (eller på anden måde lækker).


MVH
Rune Jensen

---

Rune Jensen wrote:

> Det er det, jeg mener, botterne eller spammerne skal jo først finde
> siden, før de kan finde ud af, om den har interessante spamfelter.

Ja, selvfølgelig skal de først finde siden.

> Det er nu heller ikke så svært at tilrette sin søgning med Google - mon
> folk ved, HVOR mange ting, man kan finde med den søgemaskine, som folk
> tror, de har for sig selv?

Jeg er faktisk lidt i tvivl om hvor maget de bruger Google, og hvor meget de
selv harvester.

Jo det er rigtigt, at de _har_ brugt Google (den med viewtopic.php), men
efter det er opdaget tror jeg Google har sat kraftigt ind for at forhindre
den slags.

Tænk bare på den der 'you seem to be doing automatic posts', som jeg fik.

Der er ikke det store problem at sætte en stribe sot'er til at trawle
internettet, og rapportere 'interessante' links/inhold til en central
database.

Jeg tænker her på de der JAVA klodser, der tydeligt trawler siden.

De undersøgelser og Gogglerier på den slags tyder kraftigt på det er lyssky.

En anden indikation er vores utallige forsøg på at køre remote PHP kode, det
giver jo ingen mening hvis de bruger google, eller i det mindste tjekker
URL'en for .asp

Så jeg er overbevist om, at de blot 'hugger løs'.

Her tænker jeg på de automatiserede bot'er, for ved større interessante
sites, er det nok værd at ofrer lidt 'human' indsats.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Så jeg er overbevist om, at de blot 'hugger løs'.

Hmm.. jeg er ved at kigge på nogle forskellige ting, og i den forbindelse
har der åbenbart været besøg:
<http://w-o-p-r.dk/cms/post.asp>

Det var egentlig bare noget skrammel jeg downloadede, og installerede for at
tjekke kvaliteten af diverse 'cms'-er.

Men nogen har åbenbart fundet vej

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Stig Johansen wrote:
>
>> Så jeg er overbevist om, at de blot 'hugger løs'.
>
> Hmm.. jeg er ved at kigge på nogle forskellige ting, og i den forbindelse
> har der åbenbart været besøg:
> <http://w-o-p-r.dk/cms/post.asp>
>
> Det var egentlig bare noget skrammel jeg downloadede, og installerede for at
> tjekke kvaliteten af diverse 'cms'-er.
>
> Men nogen har åbenbart fundet vej

Venkman: He slimed me...!
Ray: Hey, that's great! Actual Physical Contact!!
Egon: That's great, Ray. Save some samples for me...

;)


MVH
Rune Jensen

---

Birger Sørensen skrev:

> En bot - eller andre, hvis hensigt er at genere - kan altså ikke bare
> sende data i et væk til scriptet der modtager data. Jeg tror det er den
> slags, Philip er nervøs for.
>
> Og selvfølgelig kan det omgås hvis man er ihærdig nok. Det er der vist
> ikke noget der ikke kan.

Jeg tror nu ikke, jeg er helt gal på den.

"Browsers identify themselves by "User-Agent" HTTP headers. This header
does not normally change during use; it would be extremely suspicious if
that were to happen. A web application might make use of User-Agent
detection in attempt to prevent malicious users from stealing sessions."

http://en.wikipedia.org/wiki/Session_fixation

Grunden til, jeg laver en ID ud af user-agent, er fordi, man skal gemme
den information et sted, så den følger sessionen, og en fixed-lenght ID
er ikke direkte til at oversætte for andre, det er den rene user-agent
til gengæld.

Men ellers anbefaler Wikipedia kryptering som det stærkeste våben, SVJKS.


MVH
Rune Jensen

---

Rune Jensen skrev:
> Birger Sørensen skrev:
>
>>> Jeg sætter ikke nogle felter clientside, som der skal 'gættes'.
>>
>> Ud over session-cookien, sætter jeg heller ikke noget clientside.
>> Men det gør jeg serverside.
>
> Man kan lave et fingerprint (en slags GUID) sat sammen af f.eks. user
> agent, IP og accept-language. Det kan f.eks. være at tage alle tal eller
> ASC-værdier i user agent, IP og accept-language, lægge dem sammen og
> ANDe med en værdi a la 2^n-1, lægge disse tal sammen og igen ANDe. På
> den måde får man en nogenlunde unik værdi for lige dén bruger.

En anden måde, der er velegnet til formålet er at sætte user agent og ip
og accept-language sammen og køre det gennem MD5 digest eller SHA1 digest.

Gunnar

---

Birger Sørensen wrote:

> En bot kan altså ikke bare kalde scriptet der indsender data - formen
> _skal_ være vist (hentet, i hvert fald) for den samme SESSION, een gang
> for hver submit.

Det fremgik måske ikke så tydeligt at mine indlæg, men bot'er _henter_
_altid_ data før submit.
Kig i din log, og du vil garanteret ikke finde unsolicited POST's.

Så sekvensen er:
1) GET data med <form>
2) POST data med udfyldte felter i <form>

Ad 1)
Vær opmærksom på her, at der kan være risiko for malware hvis man klikker på
referrer.

Ad 2)
Udfyldte felter afhænger af navne, hvor der ikke er 100% hitrate på andet
end comment/message/email af dem vi har prøvet.

Ad 1+2)
Det Rune skriver om er, at de fleste bot'er sender POST umiddelbart i
forlængelse af GET, så man kan tjekke tidsintervallet mellem visning og
'udfyldelse' for en sandsynlighed.
Dog har vi set bot'er, der venter de her ca. 20 sekunder mellem GET og POST.
Google bla. bruger sådan et tjek, og derfor bliver bot'erne 'klogere'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen frembragte:
> Birger Sørensen wrote:
>
>> En bot kan altså ikke bare kalde scriptet der indsender data - formen
>> _skal_ være vist (hentet, i hvert fald) for den samme SESSION, een gang
>> for hver submit.
>
> Det fremgik måske ikke så tydeligt at mine indlæg, men bot'er _henter_
> _altid_ data før submit.
> Kig i din log, og du vil garanteret ikke finde unsolicited POST's.
>
> Så sekvensen er:
> 1) GET data med <form>
> 2) POST data med udfyldte felter i <form>
>
> Ad 1)
> Vær opmærksom på her, at der kan være risiko for malware hvis man klikker på
> referrer.
>
> Ad 2)
> Udfyldte felter afhænger af navne, hvor der ikke er 100% hitrate på andet
> end comment/message/email af dem vi har prøvet.
>
> Ad 1+2)
> Det Rune skriver om er, at de fleste bot'er sender POST umiddelbart i
> forlængelse af GET, så man kan tjekke tidsintervallet mellem visning og
> 'udfyldelse' for en sandsynlighed.
> Dog har vi set bot'er, der venter de her ca. 20 sekunder mellem GET og POST.
> Google bla. bruger sådan et tjek, og derfor bliver bot'erne 'klogere'.

Jeg _har_ haft direkte POSTs til script der skal modtage data fra fra
en <form>.

Om det så er fra bot'er, eller suspecte indivdder, kan jeg ikke vide.
(Og jeg gik ikke så meget op i det. Videresendte skidtet til ISP'en i
stedet, med en høflig anmodning om at bede sine kunder om ikke at
(mis)bruge vores kontaktform til pornoreklamer og andet bras - samtidig
med at jeg gjorde dem opmærksom på, at fremtidige "kontaktanmodninger"
fra den aktuelle IP ville ende i hans indbox, helt automatisk.)

En bot er selvfølgelig nødt til at hente formen mindst een gang, for at
vide hvad den skal sende. Men derefter er det vel ikke nødvendigt.
(Uden hermed at antyde, at din/jeres research ikke er rigtig!)

Og det er da rigtigt, at jeg indførte begge dele omtrent samtidig, så
jeg kan ikke vide, om det er SESSION tingen der virker, eller kontakten
til ISP'en der gør forskellen...
^^
Vil mene, at hvis det kun er truslen om rapporter til ISP'en, så
snakker de bot'er meget sammen, og er meget bange for deres ISP. Det er
meget længe siden, der har været noget overhovedet..

Birger

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

---

Birger Sørensen wrote:

> En bot er selvfølgelig nødt til at hente formen mindst een gang, for at
> vide hvad den skal sende. Men derefter er det vel ikke nødvendigt.
> (Uden hermed at antyde, at din/jeres research ikke er rigtig!)

Selvfølgelig er researchen rigtig.
De der blog/comment spam bot's henter altid før en POST, og nogle gange
holder de den her 'kunstnerpause'.

Det varierer og det jeg mente andet steds var 'op til ca. 20 sekunder', ikke
at jeg husker de eksakte tal.

Der er trods alt tale om mange tusinde requests fordelt over et års tid.

Men du kan selv se udtræk for en 'tilfældig' dag i 2008:
<http://w-o-p-r.dk/test/stat.10.07.2008.html>
Bemærk at samtlige POST's har en forudgående GET.

(Dem med NACKx er ikke requests, men en logning af afvisninger)

--
Med venlig hilsen
Stig Johansen

---

Birger Sørensen skrev:

> En bot er selvfølgelig nødt til at hente formen mindst een gang, for at
> vide hvad den skal sende. Men derefter er det vel ikke nødvendigt. (Uden
> hermed at antyde, at din/jeres research ikke er rigtig!)

Med en variabel stardate, skal botten lave et brute-force-angreb for at
finde formlen, altså trial&error. Man kan ikke bruge den samme GUID hver
gang, så det hjælper intet at stjæle det fra andre heller.

Jeg kan godt forstå, det er også sådan en SESSIONID fungerer, men
fordelen med en GUID er jo, den kan sendes med formen, og den
identificerer den form i den proces på det tidspunkt. Ikke unikt, det er
ret svært, men højt oppe. Hvis man 2-vejs-krypterer GUIDen, f.eks. udfra
den URL hvor formen ligger, må det være ret svært at finde ud af
formlen. Men det kan man nok også med en SESSIONID.

Du har ganske ret i, det er ikke simpelt på nogen måde, til Philips side
er det ganske giver også bedre med din idé. Men som man siger, brændt
barn... får en del paranoia. Til rigtigt vigtige sider, ville jeg lave
det i flere tempi med forskellige levels af tjecks for brugervaliditet,
login/rettigheder, kryptering osv.

På webdesigngruppen.dk er jeg slet ikke gået så langt endnu, for
botterne er kun minimalt interesserede så længe der er noindex til
søgebotterne. Så der fejer jeg dem af ved at slå alle væk, som ikke
forstår GZIP. Men havde den "public interest", ville jeg begynde at
interessere mig for mere dybdegående metoder som ovenstående. Det er jo
ikke kun spam, det er mange andre attacks, jeg ikke vil have.


MVH
Rune Jensen

---

Rune Jensen skrev den 27-12-2009:
> Birger Sørensen skrev:
>
>> En bot er selvfølgelig nødt til at hente formen mindst een gang, for at
>> vide hvad den skal sende. Men derefter er det vel ikke nødvendigt. (Uden
>> hermed at antyde, at din/jeres research ikke er rigtig!)
>
> Med en variabel stardate, skal botten lave et brute-force-angreb for at finde
> formlen, altså trial&error. Man kan ikke bruge den samme GUID hver gang, så
> det hjælper intet at stjæle det fra andre heller.
>
> Jeg kan godt forstå, det er også sådan en SESSIONID fungerer, men fordelen
> med en GUID er jo, den kan sendes med formen, og den identificerer den form i
> den proces på det tidspunkt. Ikke unikt, det er ret svært, men højt oppe.
> Hvis man 2-vejs-krypterer GUIDen, f.eks. udfra den URL hvor formen ligger, må
> det være ret svært at finde ud af formlen. Men det kan man nok også med en
> SESSIONID.

En sessionid er pr. definition unik. Og den transporteres både frem og
tilbage, helt uden man skal gøre andet end at kalde start_session().
Men der er ikke noget der binder den til en given bruger. Og det er vel
det du skal bruge en GUID til.

> Du har ganske ret i, det er ikke simpelt på nogen måde, til Philips side er
> det ganske giver også bedre med din idé. Men som man siger, brændt barn...
> får en del paranoia. Til rigtigt vigtige sider, ville jeg lave det i flere
> tempi med forskellige levels af tjecks for brugervaliditet,
> login/rettigheder, kryptering osv.
8X

Et eller andet sted, er det et spørgsmål om, hvor meget du hæger om dit
privatliv (paranoia-niveau? ^^), eller hvor sensitive dine data er,
hvor meget det kan betale sig at gøre ud af det.
Hvis der virkelig er brug for det, skal man nok overveje at flytte til
SSL.

Birger

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

---

Birger Sørensen wrote:

> En sessionid er pr. definition unik.

Ikke heeelt unik (i PHP/IE8), men det har ikke så meget med denne
problemstilling at gøre.

Dengang jeg havde adgang til en IE8 lavede jeg noget test på Philips side.

PHP (og ASP) sætter session cookies på host niveau, så hvis du f.eks. kalder
varmeretter.dk får du en cookie med PHPSESSID for hosten varmeretter.dk
kalder du derefter www.varmeretter.dk, sættes en ny sesson på hosten
www.varmeretter.dk
IE8 kan åbenbart ikke finde ud af hvornår det er host, og hvornår det er
domæner, så den sender _begge_ cookies, med _samme_ navn (PHPSESSID).

Jeg ved ikke hvad PHP gør når den får 2 cookies med samme navn.

Ovennævnte er baseret på Philips side, så jeg ved ikke om det samme gør sig
gældende på din, blot brugt navnet som eksempel.

Endvidere kan jeg ikke huske rækkefølgen - om det var med eller uden www.
først.

Jeg nævner også ASP, men det er ikke samme problem, for her får hver cookies
et suffix, så de hedder ASPSESSIDxyzq.., og dermed er selve navnet også
unikt.

--
Med venlig hilsen
Stig Johansen

---

Birger Sørensen skrev:

> Jeg _har_ haft direkte POSTs til script der skal modtage data fra fra en
> <form>.

Og i princippet burde det jo også være nok, i hvert fald for amatørspammere.

De GET'er formularen én gang for at vide hvad de skal sende, måske 2
gange for at se forskellen fra gang til gang. Derefter kan de poste en
milliard gange, hvis de ved at de kun skal ændre en enkelt værdi i
formularen (f.eks. artiklens id-nummer) fra gang til gang for at få
beskeden til at ligge under flere artikler.

Men nu er det nogle år siden jeg sidst har været udsat for det, så jeg
tager udgangspunkt i hvad jeg opfattede at de gjorde dengang.

P.t. er mine nuværende metoder effektive nok. I hver fald så længe mine
sider ikke er mere interessante for spammere, end de er. Jeg tjekker
bl.a. på HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT, referer og om de
understøtter Gzip. Dertil det klassiske "snydefelt" skjult via CSS, som
*ikke* skal udfyldes.

Referer ved jeg udmærket godt at man kan snyde med, men hvis bestemte
ord indgår i det, er det med statsgaranti spam eller i bedste fald
forsøg på refererspam. [1]

På en enkelt ældre side har jeg brugt Birgers trick med session. Det
fungerer også stadig fint, selvom jeg ikke har de andre ting med lige der.

Hvad israelerne og andre med mere menneskelignende botter finder på af
tossestreger, er det nok svært at gardere sig imod.

Note:
[1] Jeg forstår ikke det interessante ved at lægge refererspam. Det er
jo kun mig der ser referer-linkene. Men der findes måske folk der lægger
hele deres besøgslog ud til offentligt skue?

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

---

Philip Nunnegaard skrev:

> Note:
> [1] Jeg forstår ikke det interessante ved at lægge refererspam. Det er
> jo kun mig der ser referer-linkene. Men der findes måske folk der lægger
> hele deres besøgslog ud til offentligt skue?

Læs her for en forklaring, samt script (ASP):
http://runejensen.dk/artikler/referer_spam.asp

Referrer Karma (PHP) tager den steppet videre end mit script. Jeg er
ikke meget for en så stor overbygning alene til én form for spam, det
kræver hele tiden opdatering, og så forsvinder det generiske. Her ville
jeg gerne holde det forholdsvist simpelt, og så leve med de få sorte
får, der slipper igennem, hellere end at man få blacklistet en valid
bruger. Som alt andet sikkerhed bør man ikke tro på kun én form for
sikring, men tage det lidt ad gangen..

http://unknowngenius.com/blog/wordpress/ref-karma/


MVH
Rune Jensen

---

Rune Jensen skrev:

> Jeg er
> ikke meget for en så stor overbygning alene til én form for spam, det
> kræver hele tiden opdatering, og så forsvinder det generiske.

Med "generisk" går jeg ud fra at du går efter ting hvor man bare kan gå
efter nogle overordnede regler som f.eks. tid mellem GET og POST, Gzip osv.

Så længe jeg ikke selv oplever refererspam som et stort problem hos mig,
gider jeg heller ikke nogen større overbygning for dét.

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

---

Philip Nunnegaard skrev:

> Note:
> [1] Jeg forstår ikke det interessante ved at lægge refererspam. Det er
> jo kun mig der ser referer-linkene. Men der findes måske folk der lægger
> hele deres besøgslog ud til offentligt skue?

_MANGE_ flere end du tror. Jeg vil ikke give søgestrengen her, men tænk
lidt over det, er det nok ikke så svært ;)


MVH
Rune Jensen

---

Rune Jensen skrev:

>> Men der findes måske folk der
>> lægger hele deres besøgslog ud til offentligt skue?
>
> _MANGE_ flere end du tror. Jeg vil ikke give søgestrengen her, men tænk
> lidt over det, er det nok ikke så svært ;)

Det overrasker mig.

På mit webhotel skal jeg logge ind på kontrolpanelet for at se den slags.
Min egen hjemmelavede statistik er også lagt ind under login, men
indeholder dog heller ikke andet end tørre tal. Ingen sidehenvisninger
eller andet som kan give spammere blod på tanden!

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

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:
>
>>> Men der findes måske folk der lægger hele deres besøgslog ud til
>>> offentligt skue?
>>
>> _MANGE_ flere end du tror. Jeg vil ikke give søgestrengen her, men
>> tænk lidt over det, er det nok ikke så svært ;)
>
> Det overrasker mig.
>
> På mit webhotel skal jeg logge ind på kontrolpanelet for at se den slags.
> Min egen hjemmelavede statistik er også lagt ind under login, men
> indeholder dog heller ikke andet end tørre tal. Ingen sidehenvisninger
> eller andet som kan give spammere blod på tanden!

Det vil sige, at din statistik over referers, sider, som linker til dig,
altså _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
eller søgbart?

....for så er du meget heldig. Det er standardindstillingen på den gratis
statistik på mit webhotel, og selv om jeg har gjort dem opmærksom på
problemet, lader de ikke til at kunne forstå det. "Det vil kræve for
meget tid at ændre", som de siger.

Referrer spam er ikke så meget minded på dem, som _ved_ hvad det er, for
de kan nemt undgå det, men på begyndere. Sådan fik jeg f.eks. STORM, så
jeg taler af bitter erfaring....... og Stigs side, som hensvises til fra
min side, fortæller ret nøjagtigt, hvordan det foregår, når man er
landet på en sådan malwareside via referrer spam. Popper op med krav om
et plugin, eller viser en falsk advarsel om virus med besked om at
"opdatere". Opdateringen er så selve virussen.

Referrer spam er vildt billigt, da det bare kræver en HEAD, ikke
nødvendigvis en GET for at fungere, og botten behøver ikke være særligt
avanceret, derfor er det også populært. Og så fordi stadig ikke mange
kerer sig særligt om det, og tager højde for det, selv om det har været
kendt LÆNGE.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Referrer spam er vildt billigt, da det bare kræver en HEAD, ikke
> nødvendigvis en GET for at fungere, og botten behøver ikke være særligt
> avanceret, derfor er det også populært. Og så fordi stadig ikke mange
> kerer sig særligt om det, og tager højde for det, selv om det har været
> kendt LÆNGE.

Nåhjha, laver man en GET, kan man kombinere referrer spammingen med
harvesting og egentlig comment-spamming, så tre-i-én.


MVH
Rune Jensen

---

Rune Jensen skrev:

> Det vil sige, at din statistik over referers, sider, som linker til dig,
> altså _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
> eller søgbart?

Der er to angrebsvektorer, som jeg også skriver på siden.

1. At statistikken er åben, og at referrers ligger i en a href, så
linket bliver indekserbart for _Google_. Det vil rykke
referrerspammenrens side højere på på Google, da denne vil opfatte det
som et link (anbefaling) af spamsiden fra din side

2. At statstikken er lukket (med login), men at referrers stadig ligger
i en a href. Her er det nysgerrigheden hos _webmasteren_, som er målet.
"Hvem linker til mig? Neeej,
www.illegalmp3russianlesbianviagranoprescriptiondrugstoreporn.ru, den MÅ
jeg simpelthen klikke på for at se, hvem det er." ...og det gør han,
fordi han STOLER på, at hvad der ligger i en statistik, som kun kan nås
via login, det er sikkert...


MVH
Rune Jensen

---

Rune Jensen skrev:


> Det vil sige, at din statistik over referers, sider, som linker til dig,
> altså _ikke_ ligger i en a href, og derfor _ikke_ er direkte klikbart
> eller søgbart?

Det er godt nok klikbart, men som sagt, så skal jeg jo logge ind på
webhotellets kontrolpanel for at kunne se det. Ergo er der kun én person
der kan se det (mig).

> "Det vil kræve for
> meget tid at ændre", som de siger.

Lyder som en dårlig undskyldning. Jeg vil tro at jeg kunne ændre sådan
noget på 5 minutter, hvis det var mig der hevde programmeret det.


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

---

Philip Nunnegaard skrev:
> Rune Jensen skrev:

>> "Det vil kræve for meget tid at ændre", som de siger.
>
> Lyder som en dårlig undskyldning. Jeg vil tro at jeg kunne ændre sådan
> noget på 5 minutter, hvis det var mig der hevde programmeret det.

Jeg var selvfølgelig inde på hjemmesiden for den gratis statistik efter,
jeg havde fået STORM. Iflg. denne side, ligger det som en parameter, som
skal ændres. Jeg kender ikke dybere til det (det er PHP), men det
faktum, at så mange hostere med samme ell. lign. statistik ikke slår
dette fra, giver mig indtryk af, at det (sikkerhed hos kunderne selv)
ikke tages særligt seriøst.

Udled af dette, hvad du vil ;)


MVH
Rune Jensen

---

Philip Nunnegaard wrote:

> Det er godt nok klikbart, men som sagt, så skal jeg jo logge ind på
> webhotellets kontrolpanel for at kunne se det. Ergo er der kun én person
> der kan se det (mig).

Ja, men til gengæld er denne ene 'mig' interessant, da det er overvejende
sandsynligt det er en administrator.

Du skal ikke tænke i reklamer osv, nærmere i malware/passwordlogger og deraf
følgende admin adgang til websitet.

Det er den slags man møder ved at klikke på referrer.

Den første 'sag' vi dybdeborede i var faktisk netop en referrer, hvor url'en
pegede på en italiensk side, der omhandlede kørselsoplevelser.

Siden var bare blevet inficeret med et <script> tag, der omstillede til
sådan en 'virusscanner', så brugeren ville blive mødt med en advaesel om
virus og anbefaling om at installere 'antivirus'.

Den 'sag' har jeg gemt med de faktiske scripts fra de forskellige layers i
processen - dog er URL'erne ændret:
<http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>

Her kan du se hvad der ville ske hvis man klikkede på linket.

Hvis du aktiverer den, får du blot en lille showmessage (lige som en JS
alert) jeg har lavet, og ikke den rigtige malware, men den illusterer meget
godt hvor svært det er et undgå inficering.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:

> Den 'sag' har jeg gemt med de faktiske scripts fra de forskellige layers i
> processen - dog er URL'erne ændret:
> <http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>
>
> Her kan du se hvad der ville ske hvis man klikkede på linket.

Lille "sag", men STOR virkning ;)

Klart, det er slet ikke interessant for webhostere at stoppe dette,
hvorfor skulle de dog det, selvom det er nemt, for det er jo slet ikke
til fare for nogens sikkerhed... Nybegyndere eller uvidende ville heller
ALDRIG klikke på et klikbart link i deres statistik af nysgerrighed -
vel... Så det er DUMT at spilde tid på for en webhoster...

....Kunne ikke dy mig, sorry.


MVH
Rune Jensen

---

Rune Jensen wrote:

> ...Kunne ikke dy mig, sorry.

Jeg synes nu det er helt fint at påpege, for 'de' udnytter jo netop det med
at en webmaster synes:
Orv - jeg har fået besøg fra Italien - gad vide hvem det er? - BANG!

At udbyderne ikke kan/vil ændre links til ikke klikbare siger lidt om deres
(manglende) kompetence.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Rune Jensen wrote:
>
>> ...Kunne ikke dy mig, sorry.
>
> Jeg synes nu det er helt fint at påpege, for 'de' udnytter jo netop det med
> at en webmaster synes:
> Orv - jeg har fået besøg fra Italien - gad vide hvem det er? - BANG!
>
> At udbyderne ikke kan/vil ændre links til ikke klikbare siger lidt om deres
> (manglende) kompetence.

Mit udgangspunkt for i det hele taget at interesserer mig for det, var,
at jeg selv fik en infektion. Men...

Adskillige statistikker og unders'gelser tyder på, at DK ligger omend
MEGET højt, hvad angår generel sikkerhed. Det kan være spamming (hvor er
de danske spambots? Klart, der er nogen, men det er så få... og jeg har
ALDRIG været spammet eller fået injectionforsøg fra en dansk bot)

Denne høje sikkerhed er en torn i øjet på angriberne af flere årsager.
De har dyrket deres marked i lang tid vis Rusland, Kina, selv Holland
har fået et ret dårligt repuration. Men DK er mere troværdig, i og med,
"de" ikke har så høj succes her. Så at få angrebet danske sider og
servere og PCer i al almindelighed, vil helt klart få en del til at gå i
fælden. Vi er slet ikke forberedt til sådanne angreb, fordi vi aldrig
har prøvet det.

Nuvel, for at holde standarden, er vi nødt til at komme foran, og BLIVE
foran disse angribere. Og det kræver, at vi oplyser hinanden om risiko,
giver generelle must-have sikkerhedsråd og opforderer til alm. god sund
fornuft, kort sagt er KRITISKE som bare fanden, når vi er konlet til
nettet på den ene eller anden måde.

Og her er det lidt kedeligt, at bl.a. webhostere ikke vil være med på
vognen. Vi er alle i samme båd. Hvis vi vil beskytte os selv, skal vi
sørge for, at også naboen har høj sikkerhed. Så det er bare med at
uddanne og oplyse og simpelthen KRÆVE af folk, de tager nogle
forholdsregler. Dette har jeg skrevet lidt om før, jeg mener bl.a. at
skolen skal have en part i dette "at færdes på nettet". Mange dårlige
vaner læres som børn.

Men altså: Oplysning, oplysning, oplysning... og så nogle grundlæggende
lovfæsteded sikkerhedskrav til f.esk. hostere og (i visse tilfælde også
webmastere), som (burde) kræve bøde eller fængsel, hvis de brydes.

For interesserede mht. sikkerhed, og hvilke lande, som har gjort det
bedst, kan jeg henvise til annual reports fra bl.a. McAfee og Trend
Micro. Men mine egne analyser af logs viser det samme som disse. DK
klarer sig flot NU, men ingen ved med fremtiden, hvis ikke vi er meget
ops på det.


MVH
Rune Jensen

---

Stig Johansen wrote:

> <http://w-o-p-r.dk/xoomer/scanner.playback/xoomer.scanner.asp>
>
> Her kan du se hvad der ville ske hvis man klikkede på linket.

Andre 'sager' kan du se skærmdump af her:
<http://w-o-p-r.dk/xoomer/wopr.xoomer.pictures.asp>
Det er kun skærmdumps, da det tager en ½ borgerkrig at lave et faktisk
playback.

Men det viser lidt om hvilken indsats, og hvilken 'troværdighed' svineørerne
lægger for dagen.
Se f.eks 'XP security center':
<http://w-o-p-r.dk/xoomer/xpsecurity.scanner.png>
og tænk på hvor mange der vil falde i sådan en fælde, da de garanteret tror
det er MS, der står bag.

--
Med venlig hilsen
Stig Johansen

---

Philip Nunnegaard wrote:

> De GET'er formularen én gang for at vide hvad de skal sende, måske 2
> gange for at se forskellen fra gang til gang.

Sludder.

> Men nu er det nogle år siden jeg sidst har været udsat for det, så jeg
> tager udgangspunkt i hvad jeg opfattede at de gjorde dengang.

Det er netop den slags udtalelser der gjorde, at jeg/vi blev interesseret i
at _undersøge_ sagen i stedet for at gætte sig frem.

Nettet er fyldt med forkerte antagelser, så det kunne ikke bruges til noget.

De laver altid en GET før en POST, og nogle laver også en efterfølgende GET
for at tjekke om indholdet blev opdateret.

Hvis du kigger på det udtræk fra en dag i 2008, kan du se et eksempel på en
af de mere 'avancerede' bot'er.

Se efter IP adressen: 79.143.176.19, og her fremgår det tydeligt at:
1) Den venter 17 sek. fra GET til POST for at undgå det med tiden.
2) Den laver et kontrolopslag (GET) efter POST.

Hvis man følger lidt med i diverse medier, så er kvalitet også blevet et
krav til sælgere af spam, så de handler med 'guaranteed' succes når de
sælger blog/comment spam eller email adresser, så derfror er
kontrolopslaget nødvendigt.

> P.t. er mine nuværende metoder effektive nok. I hver fald så længe mine
> sider ikke er mere interessante for spammere, end de er. Jeg tjekker
> bl.a. på HTTP_ACCEPT_LANGUAGE, HTTP_ACCEPT, referer og om de
> understøtter Gzip. Dertil det klassiske "snydefelt" skjult via CSS, som
> *ikke* skal udfyldes.

Det er fint når det virker godt nok, men derfor er det jo meget rart at vide
hvilke metoder de bruger.

Hvis du kigger på ovennævnte udtræk, kan du se, at de benytter URL'en fra
GET til referrer i POST, så at tjekke på referrer i en POST kan du ikke
bruge til en skid.

Ud over den log som jeg har lagt et udtræk af, har vi også en kæmpe log med
feltnavne og indhold, der forsøges POST'et.

Heraf fremgår det, at det er ligegyldigt om du bruger type=hidden eller om
du 'skjuler' det vha CSS.

Det er alene feltnavnet der styrer hvad der bliver sendt.

Og der er intet gætteri eller gentagne forsøg fra bot'erne, helt klart kun
en slags 'dictionary'.

Så <email> bliver udfyldt med emal adresse, <comment>/<message> bliver fyldt
med en bunke links til viagra/porno/nøgenbileder osv.

Resten af de feltnavne vi har prøvet bliver udfyldt lidt i flæng.

Det betyder at det eneste reelle feltnavn (af dem vi har prøvet) man kan
bruge er email, da comment/message vil medføre for meget ekstra trafik.

Jeg blev først lidt overrasket over noget af indholdet i vores log, for jeg
havde lagt et dato og tid felt ind for at se hvad de havde tænkt sig at
skrive.
Indtil det gik op for mig, at dato (date) også betød (kæreste)aftale :)

> Hvad israelerne og andre med mere menneskelignende botter finder på af
> tossestreger, er det nok svært at gardere sig imod.

De der 'israelere'/'tyrkere' er mennesker.
Der findes 'bureauer', der lever af at lægge links og anbefalinger ind til
givne websteder, så de kan få en højere pagerank.

> [1] Jeg forstår ikke det interessante ved at lægge refererspam.

Se mit andet svar.

--
Med venlig hilsen
Stig Johansen

---

Philip Nunnegaard skrev:
> Da jeg ikke kan finde ud af at lave det unobtrusive, passer jeg dog lidt
> på hvor jeg bruger det.
>

Ja jeg sidder netop og læser på nettet om unobtrusive i forhold til
JavaScript. Min plan med alle projekter er blandt andet:
* Implementer HTML og CSS
* Test om det virker
* Implenter JavaScipt og DOM
* Test om det virker

Så jeg vil gå tilbage til læsningen af dette unobtrusive begreb.

Gunnar

---

Gunnar Vestergaard wrote:

> Ja jeg sidder netop og læser på nettet om unobtrusive i forhold til
> JavaScript. Min plan med alle projekter er blandt andet:
> * Implementer HTML og CSS
> * Test om det virker
> * Implenter JavaScipt og DOM
> * Test om det virker

Nu skriver du ikke så meget om metoden, men jeg synes det kan være en fordel
først at udvikle med inline JS, og derefter 'unobtrusive-fisere det'.

Det kan være lettere at overskue(fejlfinde) i starten.

Udviklingsmetoder er subjektive, så det er min personlige holdning, og ikke
en endegyldig 'sandhed'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Gunnar Vestergaard wrote:
>
>> Ja jeg sidder netop og læser på nettet om unobtrusive i forhold til
>> JavaScript. Min plan med alle projekter er blandt andet:
>> * Implementer HTML og CSS
>> * Test om det virker
>> * Implenter JavaScipt og DOM
>> * Test om det virker
>
> Nu skriver du ikke så meget om metoden, men jeg synes det kan være en fordel
> først at udvikle med inline JS, og derefter 'unobtrusive-fisere det'.

Det er sådan, jeg laver CSS, så på den måde er der ikke så meget forskel.

Altså først inline CSS på selve elementerne, derefter rykker jeg det i
<head>, og fjerner ens egenskaber, laver classer, IDer osv., så er det
direkte til at smide eksternt bagefter. Det er en slave-metode, men den
virker.

Forskellen til JS er jo nok det med eventhandlers; det skal lige sive
ind først, hvilket jeg stadig selv er i gang med. Måske kan det
sammenlignes netop med at lave IDer og classer i CSS udfra inline style.

Mht. eventhandlers, tror jeg opretter ny tråd i clientside.


MVH
Rune Jensen

---

Rune Jensen wrote:

> Det er sådan, jeg laver CSS, så på den måde er der ikke så meget forskel.
>
> Altså først inline CSS på selve elementerne, derefter rykker jeg det i
> <head>, og fjerner ens egenskaber, laver classer, IDer osv., så er det
> direkte til at smide eksternt bagefter. Det er en slave-metode, men den
> virker.

Det er nøjagtigt det samme i min optik.

I forbindelse med udvikling, så er det meget nemmere at skrive f.eks.
onclick="do.something(this)" osv.
på den måde kan man udvikle og afteste at skidtet virker.

Når det så virker, kan man altid udskille javascript i head/eksterne filer,
for man ved at de fundamentale funktioner virker.

Så eventuelle fejl er ved udskillelsen, og ikke funktionaliteten.

--
Med venlig hilsen
Stig Johansen

---

Rune Jensen formulerede spørgsmålet:
> oz7aik skrev:
>
>> hvad er AJAX.?
>
8X
> AJAX er en blanding af javascript og serverside.
8X

AJAX er et navn for en teknologi, der anvender et object der hedder
XMLHttpRequest der er indbygget i moderne browsere (eller et ActiveX
object i ikke så moderne).
Det *kan* anvendes af javascript - men også af andre clientside
scriptsprog som VB f.eks.
Det *kan* anvendes til overførsel af XML - men også til overførsel af
andre typer data som HTML og helt almindelig tekst f.eks.

Birger

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

---

Birger Sørensen sendte dette med sin computer:
> Rune Jensen formulerede spørgsmålet:
>> oz7aik skrev:
>>
>>> hvad er AJAX.?
>>
> 8X
>> AJAX er en blanding af javascript og serverside.
> 8X

Der smuttede lige lidt :

AJAX har ikke rigtigt noget med serverside at gøre.
Det henter eller bringer selvfølgelig data til og fra script
clientside, som en <form> ville - men scriptet clientside, er et helt
almindeligt script, og ikke (nødvendigvis) tilpasset AJAX.

Forskellen på en <form> og et AJAX kald, er at formen er beregnet til
at returnere en hel side, mens AJAX kan returnere hvad som helst, og
det er programmørens opgave at sørge for at (evt.) returnerede data
vises som de skal.

Birger

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

---

oz7aik skrev den 26-12-2009:
> "Christian Kragh" <tursoe@gmail.com> skrev i meddelelsen
> news:4b35d1a9$0$278$14726298@news.sunsite.dk...
>>>> hvad kan man gøre så det automatisk sker
>>>
>>> Prøv forslaget på http://html-faq.dk/1006.asp
>>
>> Det er noget pjat, så skal brugeren hente en masse ned blot for at der er
>> ændret en smugle...
>>
>> Brug AJAX og hent kun det nye indhold, så er det ikke opsætningen, grafik,
>> ect. der skal hentes igen...
>>
>> Man kan bruge dit trix på den side med det dynamiske indhold...
>>
>> Christian
>
> Tak for alle svarene
>
> hvad er AJAX.?
>
> ps. jeg bliver nok aldrig færdig med mine sider, rette stavefejl, nye love
> m.m.
>
> JbP
>
> http://www.oz7aik.dk/faglig/

Som Allan skriver er det overkill, og en meget skidt grund til at bruge
AJAX. For selv med AJAX, kan returneres "ingen ændring" - eller 304.

Jeg opfatter spørgsmålet, som at spørgeren oplever problemer hos sig
selv, når siden opdateres.
Sæt browseren til at checke hver gang i stedet for at bruge cache - sæt
evet cache størrelsen til 0.

Birger

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

---

Christian Kragh skrev:

> Brug AJAX og hent kun det nye indhold, så
> er det ikke opsætningen, grafik, ect. der skal
> hentes igen...

Det er fuldstændig overkill i dette tilfælde - manden
aner jo ikke hvad du snakker om.

Jeg kom med en løsning der kan bruges generelt,
hvorfor bringer du så Ajax ind i probematikken?

Ajax kan mange andre ting, men ikke lige løse
Jørgens problem her og nu.

--
Allan Vebel
http://vebel.dk | http://html-faq.dk