Qual è il tuo approccio di condivisione dei cookie cross-domain preferito?

Vedo che il trucco iframe / p3p è il più popolare in circolazione, ma personalmente non mi piace perché javascript + fields + frame nascosti lo rendono davvero un lavoro di hacking. Ho anche trovato un approccio master-slave che utilizza il servizio web per comunicare ( http://www.15seconds.com/issue/971108.htm ) e sembra migliore perché è trasparente per l’utente ed è robusto contro diversi browser.

Esistono approcci migliori e quali sono i pro e i contro di ciascuno?

Il mio approccio designa un dominio come dominio “centrale” e tutti gli altri come domini “satellite”.

Quando qualcuno fa clic su un link di “accesso” (o presenta un cookie di accesso persistente), il modulo di accesso invia i suoi dati a un URL che si trova sul dominio centrale, insieme a un elemento nascosto che indica da quale dominio proviene (solo per comodità, quindi l’utente viene reindirizzato in seguito).

Questa pagina nel dominio centrale procede quindi a impostare un cookie di sessione (se l’accesso è andato bene) e redirect a qualsiasi dominio l’utente abbia effettuato l’accesso da, con un token appositamente generato nell’URL che è univoco per quella sessione.

La pagina all’URL del satellite quindi controlla quel token per vedere se corrisponde a un token che è stato generato per una sessione e, in tal caso, reindirizza a se stesso senza il token e imposta un cookie locale. Ora quel dominio satellite ha anche un cookie di sessione. Questo reindirizzamento cancella il token dall’URL, in modo che sia improbabile che l’utente o qualsiasi crawler registrerà l’URL contenente quel token (anche se se lo facesse, non dovrebbe importare, il token può essere un token monouso).

Ora, l’utente ha un cookie di sessione sia nel dominio centrale che nel dominio satellite. Ma cosa succede se visitano un altro satellite? Bene, normalmente, apparirebbero al satellite come non autenticati.

Tuttavia, in tutta la mia applicazione, ogni volta che un utente è in una sessione valida, tutti i collegamenti alle pagine degli altri domini satelliti hanno un “s” o un “s” aggiunto ad essi. Riservo a questa stringa di query di “significare” verificare con il server centrale perché riteniamo che questo utente abbia una sessione “. Cioè, nessun token o id di sessione viene mostrato su nessuna pagina HTML, solo la lettera “s” che non può identificare qualcuno.

Un URL che riceve un tag di query di questo tipo, se non c’è ancora una sessione valida, esegue un reindirizzamento al dominio centrale dicendo “puoi dirmi chi è?” inserendo qualcosa nella stringa di query.

Quando l’utente arriva al server centrale, se è autenticato lì il server centrale riceverà semplicemente il proprio cookie di sessione. In seguito invierà l’utente al satellite con un altro token monouso, che il satellite tratterà come un satellite dopo l’accesso (vedi sopra). Ad esempio, il satellite ora configurerà un cookie di sessione su quel dominio e reindirizza a se stesso per rimuovere il token dalla stringa di query.

La mia soluzione funziona senza script o supporto iframe. Richiede l’aggiunta di “? S” a qualsiasi URL tra domini in cui l’utente potrebbe non disporre ancora di un cookie a tale URL. Ho pensato a un modo per aggirare questo problema: quando l’utente accede per la prima volta, imposta una catena di reindirizzamenti intorno a ogni singolo dominio, impostando un cookie di sessione su ognuno di essi. L’unica ragione per cui non l’ho implementato è che sarebbe complicato in quanto dovresti essere in grado di avere un ordine set in modo che questi reindirizzamenti si verifichino e quando fermarsi, e ti impedirebbero di espandersi oltre i 15 domini o giù di lì (troppi di più e si avvicina pericolosamente al “limite di reindirizzamento” di molti browser e proxy).

Questa è una buona soluzione se hai il pieno controllo di tutti i domini back-end. Nella mia situazione ho solo il controllo client (javascript / html) su uno e il controllo completo su un altro, quindi ho bisogno di usare il metodo iframe / p3p, che fa schifo :(.

L’esempio in quell’articolo mi sembra sospetto perché in pratica si reindirizza a un url che, a sua volta, passa le variabili al tuo dominio in una querystring.

Nell’esempio, ciò significherebbe che un utente malintenzionato potrebbe semplicemente accedere a http://slave.com/return.asp?Return=blah&UID=123 “e accedere a slave.com come utente 123.

Mi manca qualcosa, o è risaputo che questa tecnica è insicura e non dovrebbe essere usata per, beh, le cose come suggerisce quell’esempio (passando id utente in giro, presumibilmente per rendere portatile la propria id quadro).

@thomasrutter

Potresti evitare di dover gestire tutti i link in uscita sui satelliti (aggiungendo “s” a querystring) effettuando una chiamata ajax per controllare il dominio “centrale” per lo stato di autenticazione al caricamento della pagina. È ansible evitare le chiamate ridondanti (nei successivi caricamenti di pagina) effettuando solo una sessione per sessione.

Sarebbe verosimilmente meglio rendere la richiesta di controllo dell’autenticità sul lato server prima del caricamento della pagina in modo che (a) si abbia un accesso più efficiente alla sessione, e (b) si saprà al rendering della pagina indipendentemente dal fatto che l’utente abbia effettuato l’accesso ( e visualizzare i contenuti di conseguenza).

Utilizziamo la concatenazione dei cookie, ma non è una buona soluzione poiché si interrompe quando uno dei domini non funziona per l’utente (a causa di filtri / firewall, ecc.). Le nuove tecniche (compresa la tua) si interrompono solo quando il server “master” che distribuisce i cookie / gestisce le interruzioni di accesso.

Notare che il tuo return.asp può essere abusato per redirect a qualsiasi sito (vedi questo ad esempio).

Ok, sembra che tu abbia trovato una soluzione, puoi creare un tag script che carica lo src del dominio che vuoi impostare / ottenere sui cookie … solo il safari finora sembra non essere in grado di impostare i cookie, ma Ie6 e FF funziona bene … comunque se vuoi solo OTTENERE i cookie, questo è un ottimo approccio.

Dovresti anche convalidare le informazioni sulla sessione triggers sui domini b, c, d, … in questo modo puoi accedere solo se l’utente ha già effettuato l’accesso al dominio a.

Quello che fai è sul dominio che riceve le variabili che controlli l’indirizzo del referrer, così puoi confermare che il link proveniva dal tuo dominio e non qualcuno semplicemente digitando il link nella barra degli indirizzi. Questo approccio funziona bene.