Re: Spørgsmål omkring redirects (og cookies)
Stig Johansen
> Jeg kunne godt t�nke mig at vide, om dette er korrekt beskrivelse af
> problemerne, men specielt denne:
>
> http://webdesigngruppen.dk/designteknik/www_ikke_www.asp#problems_other
>
> ...vil jeg gerne have svar p�, om er korrekt opfattet.
Jeg tror du skal pr�ve dig frem.
En ting er standarder, i det her tilf�lde RFC 2965, og noget andet er hvad
'man' g�r.
I forhold til din problemstilling, tager vi disse fra examples:
....
* A Set-Cookie2 with Domain=ajax.com will be accepted, and the
value for Domain will be taken to be .ajax.com, because a dot
gets prepended to the value.
....
heraf fremg�r det, at en cookie p� runejensen.dk er lovlig.
Kigger vi ogs� p�:
....
* A Set-Cookie2 from request-host x.foo.com for Domain=.foo.com
would be accepted.
....
heraf fremg�r det, at en cookie p� runejensen.dk vil blive accepteret af
www.runejensen.dk
Men kun dertil, for:
....
* A Set-Cookie2 from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.
....
betyder at cookien ikke vil blive accepteret ved f.eks mig.www.runejensen.dk
Det var standarden.
Men disse 'session' cookies bliver 'automagisk' dannet i 'ting' som ASP og
PHP m.fl., s� man har ikke selv kontrol over hvad der s�ttes hvor.
Mit bedste bud er nok at s�tte browseren op til at sp�rge om cookies, og se
hvad der fors�ges sat.
Eller m�ske bedre, at kigge vha. proxytrace eller lignende.
Et andet sp�rgsm�l er hvad browserne accepterer.
Der er strammet op p� det omr�de(ogs�) aht. sikkerhed.
--
Med venlig hilsen
Stig Johansen
Rune Jensen
> Mit bedste bud er nok at s�tte browseren op til at sp�rge om cookies, og se
> hvad der fors�ges sat.
>
> Eller m�ske bedre, at kigge vha. proxytrace eller lignende.
>
> Et andet sp�rgsm�l er hvad browserne accepterer.
> Der er strammet op p� det omr�de(ogs�) aht. sikkerhed.
Dette virker s� vidt jeg kan se kun i Explorer, men...
Hvis man stemmer p� den lille afstemning p� webdesigngruppen.dk, vil man
ved at skifte til www kunne stemme igen. Jeg synes nok, jeg havde
oplevet det f�r, det var derfor, jeg tog det med. Og den afstemning er
_meget_ grundig i check at ALT brugerinput - ellers. Men ikke videre
smart, man kan g�re det.
Sjovt nok.. s� kan man godt logge p� p� non-www, og s� er man stadig
logget p� p� www og omvendt. Det kunne godt v�re domain og path, som er
sat forskelligt.
Jeg laver lige lidt flere tests. Men havde man lavet redirects helt fra
starten, ville det problem vel slet ikke opst�. Jeg kan i hvert falld
ikke se, hvordan.
PS. Philip har da haft problemer med session cookies, s� vidt jeg
husker...? M�ske er det samme problemstilling?
MVH
Rune Jensen
Rune Jensen
> Jeg laver lige lidt flere tests. Men havde man lavet redirects helt fra
> starten, ville det problem vel slet ikke opst�. Jeg kan i hvert falld
> ikke se, hvordan.
N�hjoh.. man kan bruge det fine lille utility "Tamper data" i firefox
til lidt hacking.. den stopper midt i redirecten, og s� kan man ellers
tampe l�s. Jeg kan dog ikke umiddelbart finde noget, jeg kan �ndre, som
vil �del�gge noget videre.
Jeg tror, det bedste er, hvis man l�gger redirect p� inden man i det
hele taget uploader siden f�rste gang, og inden man f�r brugere til log
in og afstemninger osv. S� undg�r man s� vidt jeg kan se session og
cookie-problemer.
Og at redirect-scriptet ligger helt i starten af koden. S� er man sikker
p�, der er redirectet, f�r noget andet starter. F.eks. hvis man laver
validering af tegn i adressbaren, det skulle gerne foretages p� end point.
Men s� kan jeg heller ikke se problemer med det script?
Ikke for HTTP i hvert fald. Jeg ved ikke med HTTPS, jeg har ikke videre
forstand p� det. Den skal m�ske tages s�rskilt..
MVH
Rune Jensen
Philip Nunnegaard
> PS. Philip har da haft problemer med session cookies, s� vidt jeg
> husker...? M�ske er det samme problemstilling?
Det kunne da v�re interessant hvis det viste sig at v�re samme
problemstilling.
Mit problem med session-cookies opleves af folk der bruger IE og
specielt IE 8.
Jeg har ikke oplevet det de browsere jeg selv bruger.
--
Philip - http://chartbase.dk | http://www.hitsurf.dk
Rune Jensen
> Rune Jensen skrev:
>
>> PS. Philip har da haft problemer med session cookies, s� vidt jeg
>> husker...? M�ske er det samme problemstilling?
>
> Det kunne da v�re interessant hvis det viste sig at v�re samme
> problemstilling.
>
> Mit problem med session-cookies opleves af folk der bruger IE og
> specielt IE 8.
> Jeg har ikke oplevet det de browsere jeg selv bruger.
S� tilgiv mig, for jeg har ikke en meter forstand p� session variable..
men s�tter du path, henholdsvist domain for de cookies?
Hm.. en lille genopfriskning af problemet, kunne ogs� hj�lpe ;) Det er
vidst noget med, de logges ud p� en eller anden m�de automatisk.
Jeg leger bare, betragt det som trial'n'error, s� ingen garanti for, det
er det, som er problemet. Men jeg er meget interesseret.
MVH
Rune Jensen
Bertel Lund Hansen
> S� tilgiv mig, for jeg har ikke en meter forstand p� session variable..
Det kan du hurtigt f�. De kan nemlig behandles som almindelige
variable, men de har den magiske egenskab at de overlever n�r man
skifter side i browseren. De d�r f�rst n�r man lukker browseren
ned.
N�r en formular f.eks. husker hvad man indtastede n�r hjemmesiden
viser samme formular igen og ovenover med r�d skrift skriver
Du glemte at udfylde telefonnummeret.
s� er det session-variable der er i spil.
--
Bertel
Jeg har f�et ny offentlig mailadresse.
Philip Nunnegaard
> S� tilgiv mig, for jeg har ikke en meter forstand p� session variable..
> men s�tter du path, henholdsvist domain for de cookies?
Sessionvariabler s�tter jeg intet p�. Det gjorde jeg heller ikke i ASP.
Da var det bare noget i retning af:
session("foo") = "bar"
Ca. det samme i PHP.
$_SESSION["foo"] = "bar";
Med "rigtige" cookies s�tter jeg derimod dom�nenavn p� ogs�.
Og de holder sig i live indtil folk lukker browseren, eller der er g�et
for lang tid uden at de har foretaget sig noget p� siden.
setcookie("foo", $sesid, time() + 43200, "/~domaene/", ".domaene.dk", 1);
43200 er antal sekunder (12 timer).
> Hm.. en lille genopfriskning af problemet, kunne ogs� hj�lpe ;) Det er
> vidst noget med, de logges ud p� en eller anden m�de automatisk.
>
> Jeg leger bare, betragt det som trial'n'error, s� ingen garanti for, det
> er det, som er problemet. Men jeg er meget interesseret.
Det er rigtigt husket.
Hvad jeg til geng�ld ikke ved, er om det f.eks. er noget folk oplever
hvis de har v�ret inde p� en side og lavet noget der har taget mere end
de 20 minutter som en session mig bekendt holdes i live som standard.
Jeg er ikke altid lige god til at tage h�jde for at jeg ikke arbejder i
en formular p� samme m�de som andre (jeg bruger f.eks. TAB flittigt,
mens de fleste andre nok udelukkende bruger musen til at flytte fokus
til et nyt felt).
Det er aldrig lykkedes mig selv at fremprovokere problemet med min IE,
s� nogle gange kunne jeg godt t�nke mig at st� og kigge brugeren over
skulderen, mens vedkommende oplever problemet.
I den nye version som jeg er ved at lave fra bunden, k�rer jeg et lille
script via AJAX, der fors�ger at holde live i sessionen med j�vne mellemrum.
Om det virker, ved jeg dog f�rst en gang til for�ret.
Rune Jensen
Hm, s� er det sp�rgsm�let, om Philips problem var det, jeg t�nkte p�.
Det var jo udfra, hvad jeg srev om, at man kunne stemme igen, hvis man
gik ind p� www-delen af webdesigngruppen, og tror jeg har noget med
domain og path at g�re.
Man kan forestille sig meget. Et andet scenarie, som vel burde
indbefatte IE8 men ogs� Chrome, hvis man k�rer Vista (ikke XP), det er,
at fanerne ikke deler med hinanden. De k�rer i hver sin sand box. S�
hvis man har et vindue, som �bnes i ny fane, kan man (m�ske?) opleve, at
cookien ikke f�lger med.
En tredje: Jeg har oplevet, at der var problemer med en nyinstalleret
chatfunktion, som skulle hente information fra login, fordi dom�ne.dk og
dom�ne.dk/ samt dom�ne.dk/index.asp er selvst�ndige URLer, men giver
samme indhold (i princippet). Det var ikke mig, som fandt p� l�sningen,
men den indebar et tjek af, hvor man kom fra, s� vidt jeg husker.
Men Philip kunne m�ske give lidt flere informationer udfra ovenst�ende.
Det bedste ville v�re, om man kunne genskabe problemet selv.
MVH
Rune Jensen
Philip Nunnegaard
> Man kan forestille sig meget. Et andet scenarie, som vel burde
> indbefatte IE8 men ogs� Chrome, hvis man k�rer Vista (ikke XP), det er,
> at fanerne ikke deler med hinanden. De k�rer i hver sin sand box. S�
> hvis man har et vindue, som �bnes i ny fane, kan man (m�ske?) opleve, at
> cookien ikke f�lger med.
Nu ved jeg ikke hvad en sand boks er, men jeg oplever ikke selv
problemer med at �bne i nye faner.
> Men Philip kunne m�ske give lidt flere informationer udfra ovenst�ende.
> Det bedste ville v�re, om man kunne genskabe problemet selv.
Det st�rste problem er s�dan set at jeg simpelt hen ikke kan
fremprovokere problemet selv. Heller ikke med IE8.
Rune Jensen
> Rune Jensen skrev:
>
>> Man kan forestille sig meget. Et andet scenarie, som vel burde
>> indbefatte IE8 men ogs� Chrome, hvis man k�rer Vista (ikke XP), det
>> er, at fanerne ikke deler med hinanden. De k�rer i hver sin sand box.
>> S� hvis man har et vindue, som �bnes i ny fane, kan man (m�ske?)
>> opleve, at cookien ikke f�lger med.
>
> Nu ved jeg ikke hvad en sand boks er, men jeg oplever ikke selv
> problemer med at �bne i nye faner.
Hver webside har deres egen tildelte hukommelsesplads fuldst�ndigt for
sig selv. Det er derfor, MS reklamerer med, at hvis �n webside g�r i
kage, s� er det kun den fane, det g�r ud over. Chrome har det samme, og
som jeg har forst�et det, er det en funktion i Vista som udnyttes til
det, hvorfor IE8 og Chrome i XP ikke k�rer i sand box.
FF, der deler alle fanerne samme hukommelsesomr�de. Jeg har s� aldrig
haft problemer med FF, s� jeg har ikke kunnet se, hvad der sker, n�r den
g�r ned. Men i princippet, s� burde hele browseren vel g� ned.
Sand boxing er vidstnok noget, som ogs� udnyttes i JAVA. Nordea har
f.eks. en JAVA-applet til log in, og det tror jeg helt klart er fordi,
s� er den beskyttet imod ting udefra.
>> Men Philip kunne m�ske give lidt flere informationer udfra
>> ovenst�ende. Det bedste ville v�re, om man kunne genskabe problemet selv.
>
> Det st�rste problem er s�dan set at jeg simpelt hen ikke kan
> fremprovokere problemet selv. Heller ikke med IE8.
OK, men s� kan du vel tracke deres f�rden via statistikken, og ogs� se,
hvor lang tid de har brugt p� hver del.
Anyways, det lader til, du har gang i en l�sning. Jeg ville selv foresl�
at s�tte tiden op, men det har du nok selv t�nkt p�. L�sningen via AJAX
er ogs� foresl�et andetsteds (et eller andet forum, jeg faldt over). S�
det kunne tyde p� den virker.
MVH
Rune Jensen
Rune Jensen
> Hver webside har deres egen tildelte hukommelsesplads fuldst�ndigt for
> sig selv. Det er derfor, MS reklamerer med, at hvis �n webside g�r i
> kage, s� er det kun den fane, det g�r ud over. Chrome har det samme, og
> som jeg har forst�et det, er det en funktion i Vista som udnyttes til
> det, hvorfor IE8 og Chrome i XP ikke k�rer i sand box.
Fra Chromium Blog:
http://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html
"In a nutshell, a sandbox is security mechanism used to run an
application in a restricted environment. If an attacker is able to
exploit the browser in a way that lets him run arbitrary code on the
machine, the sandbox would help prevent this code from causing damage to
the system. The sandbox would also help prevent this exploit from
modifying and even reading your files or any information on the system"
/Grundl�ggende, s� er en "sand box" en sikkerhedsmekanisme, som bruges
til at k�re applikationer (programmer) i et n�je afgr�nset milj�. Hvis
en angriber er i stand til at udnytte en s�rbarhed i browseren p� en
m�de, som g�r ham i stand til at k�re skadelig kode p� maskinen, s� vil
sand boxen hj�lpe med at afv�rge denne kode fra at �ndre og endda l�se
dine filer eller anden information p� systemet./
Desuden, s� st�r der lidt om, at plug ins til browseren ogs� skal sand
boxes - det arbejder de p�.
Men det er en _meget_ strict fokusering p� sikkerhed ogs�, udover
stabilitet. Og det har hackertests i�vrigt ogs� vist. Derfor, jeg tror,
at Chrome vil kunne sl� Firefox, hvis de f�r bare tiln�rmelsesvis samme
kvalitet og m�ngde i plug ins som FF...
MVH
Rune Jensen
Martin
> Jeg har beskrevet nogle metoder til at omdirigere permanent fra
> www->non-www og omvendt her:
>
> http://webdesigngruppen.dk/designteknik/www_ikke_www.asp
>
> Jeg kunne godt t�nke mig at vide, om dette er korrekt beskrivelse af
> problemerne, men specielt denne:
>
> http://webdesigngruppen.dk/designteknik/www_ikke_www.asp#problems_other
>
> ...vil jeg gerne have svar p�, om er korrekt opfattet.
I PHP (og sikkert ogs� alle server og client sprog der kan s�tte
cookies�) g�lder n�r man s�tter en cookie, s� ved default d�kker den
hele domainet, dvs. b�de www.domain.invalid sub.domain.invalid
another.domain.invalid
Man kan s� s�tte en variabel der knytter den til et fast sted, og en
anden variabel der knytter cookien til en bestemt subdirectory (og subs
til denne).
S� er der s� secure cookies aka. cookies der kr�ver https forbindelse.
S� det er faktisk helt op til udvikleren af cookien hvad den egentlig m�
og skal opf�re sig.
Martin
> http://fuckwww.dk/ :)
[Offtopic]
Havde forresten en sjov oplevelse med en kunde (midt 30 l�d det som om),
jeg sagde s� min mailadresse til denne kunde, og hun sagde at nu havde
hun sendt mailen - goodie jeg ventede s� de obligatoriske op til 30 sek.
men jeg fik endnu ingen mail ventede lidt mere... En halv times tid
efter fik jeg s� mailen... videresendt fra administrator... hmmm, s�
havde hun v�ret s� flink at skrive www.minmail@invalid ... Welcome to
the 90's
[/offtopic]
Philip Nunnegaard
> Sand boxing er vidstnok noget, som ogs� udnyttes i JAVA. Nordea har
> f.eks. en JAVA-applet til log in, og det tror jeg helt klart er fordi,
> s� er den beskyttet imod ting udefra.
Doh! Dumme mig!
Jeg l�ste ordet forkert. Jeg l�ste det som "sand boks" i mods�tning til
"falsk boks" og t�nkte: Hvad i alverden har det med checkbokse at g�re?
> OK, men s� kan du vel tracke deres f�rden via statistikken, og ogs� se,
> hvor lang tid de har brugt p� hver del.
Det er s� det jeg vil g�re, hvis brugerne stadig oplever problemet, n�r
den nye version g�r i luften.
> Anyways, det lader til, du har gang i en l�sning. Jeg ville selv foresl�
> at s�tte tiden op, men det har du nok selv t�nkt p�.
Tiden p� en session er jeg ikke s� sikker p� at jeg kan regulere (i
mods�tning til tiden for en almindelig cookie som jeg har sat til 12 timer).
> L�sningen via AJAX
> er ogs� foresl�et andetsteds (et eller andet forum, jeg faldt over). S�
> det kunne tyde p� den virker.
Det lyder opmuntrende.
Egentlig t�nkte jeg det bare som en erstatning for det jeg gjorde i
gamle dage, hvor jeg brugte frames. Jeg havde en skjult frame der
indeholdt et asp-script som ordnede sagen. Intet html-output mellem
<body> og </body>. Den lille f�tter bortfaldt naturligvis da jeg gik v�k
fra frames.
Philip Nunnegaard
> Havde forresten en sjov oplevelse med en kunde (midt 30 l�d det som om),
> jeg sagde s� min mailadresse til denne kunde, og hun sagde at nu havde
> hun sendt mailen - goodie jeg ventede s� de obligatoriske op til 30 sek.
> men jeg fik endnu ingen mail ventede lidt mere... En halv times tid
> efter fik jeg s� mailen... videresendt fra administrator... hmmm, s�
> havde hun v�ret s� flink at skrive www.minmail@invalid ... Welcome to
> the 90's
Det oplever jeg ogs� stadig en sj�lden gang imellem, men dog mest fra
urutinerede computerbrugere.
En arbejdskollega kunne ikke f� ind i sit hoved at hun ikke skulle bruge
"www" i en mailadresse.
"Det er noget med www og snabel-a, ikke?"
Ellers forbinder jeg det nu ogs� mest med sidste halvdel af 90'erne.
Stig Johansen
> Det er s� det jeg vil g�re, hvis brugerne stadig oplever problemet, n�r
> den nye version g�r i luften.
I f�rste omgang skal du v�re opm�rksom p� www ctr uden www - 'problemet'.
Jeg har lige pr�vet din side med og uden www, og der f�r jeg to separate
sessioncookies.
Hvis du et eller andet stad har det ene eller det andet, kan det godt
t�nkes, at det skaber en ny session (hvor man s� ikke er logget ind).
S� f�rste step m� v�re at f� 'normaliseret' din side.
N�h, var lige ovre og starte IE8 og proxytrace op, h�ber ikke du ventede for
l�nge ;)
Jeg startede med www.chartbase, og der fik jeg (selvf�lgelig= en session
cookie.
Derefter kaldte jeg chartbase, og her blev den f�rste ikke medsendt, s� jeg
fik en ny session cookie.
Kalder www.chartbase igen, og her sendes begge cookies.
Kalder jeg chartbase igen, sendes kun dens 'egen' cookie.
Alts� noget v�rre roderi, ikke mindst fordi PHP bruger samme navn
(PHPSESSID) i mods�tning til ASP, hvor der er et (unikt) suffix.
Hvad PHP g�r n�r den modtager dubletter ved jeg ikke, alts� om den v�lger
den f�rste eller sidste, eller m�ske random.
Om det direkte er �rsagen ved jeg ikke men det skaber i hvert fald grobund
for problemer.
Skulle man lige pr�ve samme �velse i FF?
Joh - tjekkede lige, FF sender kun sine 'egne' cookies, dvs. hver sin til
hhv www.chartbase og chartbase, men stadig to forskellige cookies, og
dermed sessions.
> Tiden p� en session er jeg ikke s� sikker p� at jeg kan regulere (i
> mods�tning til tiden for en almindelig cookie som jeg har sat til 12
> timer).
Du kan jo pr�ve at se om du har adgang:
<http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/>
>> L�sningen via AJAX
>> er ogs� foresl�et andetsteds (et eller andet forum, jeg faldt over). S�
>> det kunne tyde p� den virker.
>
> Det lyder opmuntrende.
> Egentlig t�nkte jeg det bare som en erstatning for det jeg gjorde i
> gamle dage, hvor jeg brugte frames. Jeg havde en skjult frame der
> indeholdt et asp-script som ordnede sagen. Intet html-output mellem
> <body> og </body>. Den lille f�tter bortfaldt naturligvis da jeg gik v�k
> fra frames.
S� kan du vel bare bruge en <object> med en meta refresh ?
Bortset fra det, s� vil hverken frame,object eller ajax l�se dit 'cookie'
problem.
Men du kan starte med at tjekke i din log om host har st�et med b�de www. og
uden.
Det vil give en ide om det sker eller ej.
Tjekker du ogs� referrer, s� kan du ogs� se hvor den/de kom fra.
Stig Johansen
> Det oplever jeg ogs� stadig en sj�lden gang imellem, men dog mest fra
> urutinerede computerbrugere.
Urutinerede?
<http://w-o-p-r.dk/images/fun/urutineret.jpg> :)
Bertel Lund Hansen
> Urutinerede?
> <http://w-o-p-r.dk/images/fun/urutineret.jpg> :)
P� n�ste billede tager hun vel musen og peger p� sk�rmen med den.
Stig Johansen
> Stig Johansen skrev:
>
>> Urutinerede?
>> <http://w-o-p-r.dk/images/fun/urutineret.jpg> :)
>
> P� n�ste billede tager hun vel musen og peger p� sk�rmen med den.
Ja, det lidt stort, s� man skal scrolle for at se det.
Det var bare noget jeg lige kom i tanke om jeg havde scannet fra en avis
engang - vistnok forrige �rtusinde.
Philip Nunnegaard
> Ja, det lidt stort, s� man skal scrolle for at se det.
Hos mig tilpasser det sig automatisk browservinduets st�rrelse (Firefox).
> Det var bare noget jeg lige kom i tanke om jeg havde scannet fra en avis
> engang - vistnok forrige �rtusinde.
Jeg fik lige et nostalgisk flip og genl�ste nogle af disse gamle klassikere:
http://www.guld.dk/internjet/index.php
Philip Nunnegaard
> I f�rste omgang skal du v�re opm�rksom p� www ctr uden www - 'problemet'.
Det var umiddelbart ogs� min tanke.
P� den anden side set: Hvis folk f�rst er kommet ind p� siden - med
eller uden www - vil de jo nok forts�tte med det, da alle interne links
jo er angivet som relative stier.
> Jeg har lige pr�vet din side med og uden www, og der f�r jeg to separate
> sessioncookies.
>
> Hvis du et eller andet stad har det ene eller det andet, kan det godt
> t�nkes, at det skaber en ny session (hvor man s� ikke er logget ind).
>
> S� f�rste step m� v�re at f� 'normaliseret' din side.
Taler vi her om at s�tte den der 301-redirect til det ene eller det
andet (www contra non-www)?
> N�h, var lige ovre og starte IE8 og proxytrace op, h�ber ikke du ventede for
> l�nge ;)
>
> Jeg startede med www.chartbase, og der fik jeg (selvf�lgelig= en session
> cookie.
> Derefter kaldte jeg chartbase, og her blev den f�rste ikke medsendt, s� jeg
> fik en ny session cookie.
> Kalder www.chartbase igen, og her sendes begge cookies.
> Kalder jeg chartbase igen, sendes kun dens 'egen' cookie.
>
> Alts� noget v�rre roderi, ikke mindst fordi PHP bruger samme navn
> (PHPSESSID) i mods�tning til ASP, hvor der er et (unikt) suffix.
Damn!
Men igen burde det vel l�se sig, hvis jeg satte en 301? Eller risikerer
jeg s� at g�re ondt v�rre?
> Om det direkte er �rsagen ved jeg ikke men det skaber i hvert fald grobund
> for problemer.
Det ville nu ikke forbavse mig, hvis det var medvirkende �rsag eller
m�ske ligefrem selve problemet.
> Du kan jo pr�ve at se om du har adgang:
> <http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/>
Har lige bookmarket den.
> Men du kan starte med at tjekke i din log om host har st�et med b�de www. og
> uden.
>
> Det vil give en ide om det sker eller ej.
Jeg skal vist lige smide nogle ekstra kolonner ind i min database (alts�
den tabel hvor jeg gemmer bes�gsoplysningerne). Det er min eneste adgang
til en detaljeret log. Jeg har jo ikke egen server.
> Tjekker du ogs� referrer, s� kan du ogs� se hvor den/de kom fra.
Hmmm... Good point!
Ja, det g�r jeg faktisk. Men jeg har ikke sk�nket det en tanke at jeg
kunne bruge det til det ogs�.
Stig Johansen
[snip]
Hvis du er interesseret i problemstillingen, og evt. l�sninger, s� sig frem.
Rune Jensen
> Jeg har lige pr�vet din side med og uden www, og der f�r jeg to separate
> sessioncookies.
>
> Hvis du et eller andet stad har det ene eller det andet, kan det godt
> t�nkes, at det skaber en ny session (hvor man s� ikke er logget ind).
>
> S� f�rste step m� v�re at f� 'normaliseret' din side.
Google er inde p� det samme omkring canonical linking, men jeg har ikke
helt forst�et det. Hvis jeg bruger relative stier i koden, s� l�gger
link URLen sig vel efter, hvor man er kommet ind - med eller uden www?
Noget andet m�ske relateret; Jeg b�vlede p� min afstemning med de
session cookies, som lod til at "overtage" de cookies, jeg satte i
Firefox, og pludselig havde jeg to cookies med samme navn, men
forskellige v�rdider samt en masse session cookies, og jeg kunne slet
ikke tilg� den cookie, jeg oprindeligt havde sat. Hvorvidt det er et
relateret sp�rgsm�l, ved jeg ikke, men jeg brugte _lang_ tid p� det,
specielt fordi browserne ikke opf�rste sig ens. Og ja, det var bl.a.
noget med domain og path, som bare ikke spillede - sikkert fordi jeg
endnu ikke har forst�et dem helt.
Kan det t�nkes, at de cookies, man s�tter har en default initiel domain
- www eller non-www?
MVH
Rune Jensen
Rune Jensen
> Google er inde på det samme omkring canonical linking, men jeg har ikke
> helt forstået det. Hvis jeg bruger relative stier i koden, så lægger
> link URLen sig vel efter, hvor man er kommet ind - med eller uden www?
Der er et andet "issue", som berører RSS-feeds. I Atom feeds skal man,
så vidt jeg kan se, angive en absolut sti til RSS-feedet. Vil det
kunne skabe problemer, hvis man har to indgange til det feed?
Jeg har oplevet, at specielt Opera ind i mellem har problemer med at
finde ud af, om et feed er opdateret. Selv om der ikke er rørt ved
indstillinger af opdateringsfrekvensen.
Jeg har lige lagt feed ind på kommentarer på nævnte side, nu tester
jeg så, om den vil
http://webdesigngruppen.dk/designteknik/www_ikke_www.asp?rss=true
Men rent logisk, da det er selvstændige domæner, kan jeg ikke
forestille mig andet, end det vil kunne skabe problemer hvis ikke man
angiver et unikt end point..
MVH
Rune Jensen
Rune Jensen
> Men rent logisk, da det er selvstændige domæner, kan jeg ikke
> forestille mig andet, end det vil kunne skabe problemer hvis ikke man
> angiver et unikt end point..
Og så kom jeg netop i tanke om, man jo kunne lave et underdomæne, som
hedder feeds, så er man ude over det problem.. Selv om feeds i dag vel
også er www/internet.
MVH
Rune Jensen
Stig Johansen
> Google er inde p� det samme omkring canonical linking, men jeg har ikke
> helt forst�et det. Hvis jeg bruger relative stier i koden, s� l�gger
> link URLen sig vel efter, hvor man er kommet ind - med eller uden www?
Ja, navigeringen vil se ens ud n�r man bruger relative stier, men nu snakker
vi de her autogenererede 'session' cookies.
> Og ja, det var bl.a.
> noget med domain og path, som bare ikke spillede - sikkert fordi jeg
> endnu ikke har forst�et dem helt.
>
> Kan det t�nkes, at de cookies, man s�tter har en default initiel domain
> - www eller non-www?
Du er nok blevet milj�skadet af det der fuckwww - pjat.
Du skal skelne mellem en Host, som er endpoint for en HTTP request, og s� et
Dom�ne.
Disse session cookies bliver sat til *Host*, og ikke dom�ne, s�
www.webdesigngruppen.dk og webdesigngruppen.dk er to forskellige *Hosts*
men samme *Dom�ne*.
Stig Johansen
> Stig Johansen skrev:
>
>> I f�rste omgang skal du v�re opm�rksom p� www ctr uden www - 'problemet'.
>
> Det var umiddelbart ogs� min tanke.
> P� den anden side set: Hvis folk f�rst er kommet ind p� siden - med
> eller uden www - vil de jo nok forts�tte med det, da alle interne links
> jo er angivet som relative stier.
Ja, man forts�tter med eller uden www, men session cookies..
Jeg skrev lidt om hosts vs. dom�ner i et svar til Rune.
>> S� f�rste step m� v�re at f� 'normaliseret' din side.
>
> Taler vi her om at s�tte den der 301-redirect til det ene eller det
> andet (www contra non-www)?
Ja.
>> Alts� noget v�rre roderi, ikke mindst fordi PHP bruger samme navn
>> (PHPSESSID) i mods�tning til ASP, hvor der er et (unikt) suffix.
>
> Damn!
> Men igen burde det vel l�se sig, hvis jeg satte en 301? Eller risikerer
> jeg s� at g�re ondt v�rre?
Nej, det kan kun blive bedre.
Stig Johansen
> Philip Nunnegaard wrote:
> [snip]
>
> Hvis du er interesseret i problemstillingen, og evt. l�sninger, s� sig
> frem.
Det var dog en m�rkelig formulering - jeg mente, at hvis jeg skal
teste/tjekke, s� sig frem.
Philip Nunnegaard
> Stig Johansen wrote:
>
>> Philip Nunnegaard wrote:
>> [snip]
>>
>> Hvis du er interesseret i problemstillingen, og evt. l�sninger, s� sig
>> frem.
>
> Det var dog en m�rkelig formulering - jeg mente, at hvis jeg skal
> teste/tjekke, s� sig frem.
Jeg r�ber lige op n�r det er.
Som jeg n�vnte i en tidligere tr�d, er jeg ved at kode hele siden om fra
bunden. Jeg fors�ger at tage inputtene fra denne undertr�d med i
betragtning.
Det er f�rst indenfor de sidste par uger at jeg overhovedet har sk�nket
www/non-www en tanke. Ikke i forbindelse med "mit problem", men helt
generelt.
Rune Jensen
> Stig Johansen skrev:
>
> > Stig Johansen wrote:
>
> >> Philip Nunnegaard wrote:
> >> [snip]
>
> >> frem.
>
> > Det var dog en mærkelig formulering - jeg mente, at hvis jeg skal
> > teste/tjekke, så sig frem.
>
> Jeg råber lige op når det er.
> Som jeg nævnte i en tidligere tråd, er jeg ved at kode hele siden om fra
> bunden. Jeg forsøger at tage inputtene fra denne undertråd med i
> betragtning.
>
> Det er først indenfor de sidste par uger at jeg overhovedet har skænket
> www/non-www en tanke. Ikke i forbindelse med "mit problem", men helt
> generelt.
Jeg har fundet minimum én årsag til, at man kan få problemer med
session-cookies, når der ikke redirectes, udfra Philips problem -
eller i hvert fald en lign. situation. Det handler om, at hvis folk
poster links i kommentar-felter til andre dele af siden, så kommer
hele URLen som regel med, også HTTP:// delen. Men om det så er en del
af Philips problem lige her, ved jeg ikke - det er bare en mulighed.
Jeg kunne forestille mig flere situationer, hvor en redirect vil gøre
nytte, fordi der kræves unikt indhold:
- Feeds. De kræver en unk URL.
- Reklamer. Jeg kunne forestille mig (men har endu ikke fået det
verificeret - Google er bestemt ikke venlig her), at går "klik" på
reklamer igennem to steder med samme indhold, kan man måske blive
banned for en slags "stuffing". Der sendes vel en referrer tilbage om,
hvor clicket kom fra, så er det nemt at se, den kommer fra sider med
identisk indhold. Uden altså, jeg aner en meter om Googles reklamer
iøvrigt, det er alene i denne forbindelse, det interesserer mig.
Jeg har nu lavet nogle tests på webdesigngruppen. Det indbefatter
skift fra non-www til www. Jeg hælder efterhånden lidt til den
løsning, da det lader til at give flere fremtidige muligheder. www. er
et underdomæne, som jeg ikke ved, hvordan klarer sig i forhold til
hoveddomænet, når gælder SEO (noget jeg arbejder på at finde ud af),
men jeg har ikke set nogen skrive, at www skulle være bedre eller
dårligere end non-www i ren SEO-sammenhæng, og Google selv lader også
til at være neutral på lige det punkt.
Nåh, det var såmænd bare det.
MVH
Rune Jensen
Stig Johansen
> Det handler om, at hvis folk
> poster links i kommentar-felter til andre dele af siden, s� kommer
> hele URLen som regel med, ogs� HTTP:// delen. Men om det s� er en del
> af Philips problem lige her, ved jeg ikke - det er bare en mulighed.
Det kan ogs� v�re links fra Google, Yahoo eller lignende.
Under alle omst�ndigheder er det en d�rlig ide ikke at redirecte en af
vejene (hvis man bruger, eller vil bruge sessions).
> men jeg har ikke set nogen skrive, at www skulle v�re bedre eller
> d�rligere end non-www i ren SEO-sammenh�ng, og Google selv lader ogs�
> til at v�re neutral p� lige det punkt.
Jeg kan ikke forestille mig at med eller uden www har nogen som helst
betydning for s�ge maskiner.
Default er stadig www (for http) og det vil det nok altid vedblive at v�re.
Der er jo ikke tale om at _fjerne_ www, men at tilbyde en redirect til www,
n�r der ikke angives noget.
Mit g�t vil v�re, at du ikke finder nogen st�rre sites, der ikke redirecter.