Cross-domain cookies?

[RetepV]

Hi, ik ben op zoek naar info over cross-domain cookies, cookies die je op het ene domein (b.v. www.msn.com) 'zet' zodat ze leesbaar zijn op een ander domein (b.v. www.yahoo.com). Ik neem www.msn.com als voorbeeld, die doen het met behulp van wat 'redirect' trucs.

Ik zoek info/meningen over:

* Hoe moet het.
* Hoe fout is het.
* Hoe zit het met de privacy wetgeving.

Tnx!

[leonardo1504]

OK hier gaat ie (moet toch ook te googelen zijn):

Je kan cookies op twee manieren onderverdelen:
persistent vs. session-cookies
of
first party vs. third party cookies

persistent: wordt op je schijf gezet en expireert na een bepaalde periode
session: blijft in je RAM geheugen en is weg als je de browser afsluit

first party: wordt alleen terug gestuurd naar het domein dat het cookie gezet heeft

third party: wordt ook meegestuurd met requests naar andere domains

Het laatste is wat je bedoelt.
De site die het cookie zet bepaalt wat voor cookie het is.

Hoe te gebruiken: niet, want de meeste mensen hebben hun privacy settings in IE6 zo staan dat dit soort cookies geblocked worden.
Voor meer info over privacy settings, kijk op http://www.w3c.org/p3p

Overigens zijn cookies geen doel maar een middel om van het stateless http protocol een stateful protocol te maken. Netscape heeft ze ooit bedacht. Geen doel maar een middel dus. Blijft over de vraag: wat is het doel ????

oh ja: 3rd party cookies worden nog maar nauwelijks gebruikt, ook niet door MSN. Er zijn voor serieuze sites betere middelen om dezelfde doelen te bereiken.

[Verwijderd]

in php kun je zo 3th party cookies "enablen" zodat ze ook door ie worden geaccepteerd (met de standaardinstellingen)

PHP:

<?header("P3P: CP=\"ALL\"");?>

[Verwijderd]

Misschien heb ik iets gemist maar bij mijn weten kan dat gewoon niet.

Een cookie zetten vanaf xxx.com en deze vervolgens uitlezen op yyy.com kan niet.

Wat je wel veel ziet is dat je op xxx.com een plaatje laadt van yyy.com. Op dat moment zet yyy.com dus het cookie maar lijkt het of xxx.com dat doet. Dit zie je veel met counters, banner exchanges e.d.
Echter, yyy.com is nog steeds de enige die wat kan doen met dat cookie (want die heeft hem gezet) en xxx.com kan er niks mee.

MS is met zijn IE6 met die 'security certificates' gekomen. Die voorkomen zelfs datgene wat ik hierboven beschreef maar zorgt ook voor problemen met cookies in frame's van verschillende domains e.d..
Dit kun je dan omzeilen door header("P3P: CP=\"ALL\""); te sturen.
Maar goed, dit is volgens mij dus iets anders dan waar de topicstarter het over heeft.

Een cookie zetten vanaf xxx.com en deze vervolgens uitlezen op yyy.com kan dus niet. Tussen subdomains kan het wel. Je kan wel een cookie zetten op xxx.domain.com en deze vervolgens uitlezen op yyy.domain.com.

[Verwijderd]

Op dinsdag 25 juni 2002 15:51 schreef MarcoTC het volgende:
Misschien heb ik iets gemist maar bij mijn weten kan dat gewoon niet.

Een cookie zetten vanaf xxx.com en deze vervolgens uitlezen op yyy.com kan niet.
[..]

dit is dat de browser ze niet naar een andere domain stuurt waar ze niet vanaf komen.
Maar wanneer je een header redirect naar een ander domein kan je wel cookie meesturen

[Verwijderd]

Op dinsdag 25 juni 2002 15:51 schreef MarcoTC het volgende:

Mee eens, maar ik dacht dat de topicstarter het zo bedoelde...

[RetepV]

Sorry guys dat ik wat vaag was, maar dat deed ik expres . Ik heb wel research gedaan, maar ik wilde wat onbevangen meningen hebben.

Al die dingen die jullie hier noemen maken gebruik van gaten in de specificaties, en misschien dat die gaten een volgende browser-versie wel gedicht zijn => daar ga je dan met je app.

Het doel is namelijk een soort 'certificate' op één site (xxx.com) uit te geven die op een andere site (yyy.com) gelezen kan worden. Dit kan ook prima door het certificate steeds in de URL mee te geven, maar ten eerste is dat lelijk en ten tweede moet elke pagina op yyy.com een stukje script hebben om dat certificate bij elke link mee te sturen. Daarnaast kun je het certificate kwijtraken en dan kun je opnieuw beginnen.

[DizzyWeb]

Je kan ook die certificate op de server opslaan en beschikbaar maken voor alletwee de domeinen... Zal je alleen moeten checken op andere criteria, IP, session-id's op beide site's, etc... Om maar wat te noemen.

[RetepV]

[continued]

In mijn geval heb ik dus eigenlijk helemaal geen cookie nodig, maar het is gewoon een mooie mechanisme omdat de browser wat dingen voor je oplost.

Ook kun je bij cookies opgeven dat ze alleen over SSL getransferred mogen worden. Dat heeft weer als voordeel dat de data in je cookie niet door iemand gestolen kan worden die jou dan kan gaan impersonaten.

Zo zat ik vroeger bij Clanbase (http://www.clanbase.com). Als ik daar inlogde werd er een ID gegenereerd en die werd gewoon in de URL geplaatst. Als ik die URL kopieerde en doorgaf aan een ander was hij als mij ingelogd als hij op die link klikte.

Overigens geen idee of dat bij Clanbase ooit opgelost is . Ook was het voor mezelf wel makkelijk, zo kon ik een Favorite aanmaken waarmee ik direkt bij Clanbase ingelogd was als ik er op klikte .

Maar goed, ik wil dus iets wat veiliger is dan dat. Het moet op het ene domein uitgegeven worden en op het andere domein gelezen kunnen worden, en onderweg mag het niet gestolen kunnen worden door een scriptkiddie met een TCP/IP sniffer...

edit:

Het is NIET bedoeld voor een urltracker ofzo.

[leonardo1504]

via de browser gaat het je niet lukken, tenzij je alles encrypted doet. Wat dacht je van server 2 server ???