Qual è il tuo approccio preferito alla condivisione dei cookie tra domini?

Question

Vedo che il trucco iframe / p3p è il più popolare in circolazione, ma personalmente non mi piace perché javascript + campi nascosti + frame lo fanno sembrare un lavoro di hacking. Ho anche incontrato 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?

Answer 1

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

Quando qualcuno fa clic su un link "accedi" (o presenta un cookie di accesso persistente), il modulo di accesso alla fine invia i suoi dati a un URL che si trova sul dominio centrale, insieme a un elemento modulo nascosto che dice quale dominio è arrivato da (solo per comodità, quindi l'utente viene reindirizzato successivamente).

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

La pagina dell'URL del satellite controlla quindi 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, quindi è improbabile che l'utente o qualsiasi crawler registrino l'URL contenente quel token (anche se, in tal caso, 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. E se visitassero un altro satellite? Bene, normalmente apparirebbero al satellite come non autenticati.

Tuttavia, in tutta la mia applicazione, ogni volta che un utente partecipa a una sessione valida, tutti i collegamenti alle pagine degli altri domini satellitari hanno un? s o & amp; s aggiunto a loro. Riservo che questa stringa di query significhi "verificare con il server centrale perché riteniamo che questo utente abbia una sessione". Cioè, nessun token o ID di sessione è mostrato in nessuna pagina HTML, solo la lettera 's' che non è in grado di identificare qualcuno.

Un URL che riceve tale tag di query "s", se non c'è ancora una sessione valida, farà un reindirizzamento al dominio centrale dicendo "puoi dirmi chi è?" inserendo qualcosa nella stringa della query.

Quando l'utente arriva al server centrale, se è autenticato lì il server centrale riceverà semplicemente il suo cookie di sessione. Quindi rimanderà l'utente al satellite con un altro token monouso, che il satellite tratterà come farebbe un satellite dopo il login (vedi sopra). Vale a dire, il satellite ora imposterà un cookie di sessione su quel dominio e reindirizzerà 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 tutti gli URL tra domini in cui l'utente potrebbe non disporre ancora di un cookie in tale URL. Ho pensato a un modo per aggirare questo problema: quando l'utente accede per la prima volta, imposta una catena di reindirizzamenti attorno a ogni singolo dominio, impostando un cookie di sessione su ciascuno. L'unico motivo per cui non l'ho implementato è che sarebbe complicato il fatto che avresti bisogno di avere un ordine prestabilito in cui questi reindirizzamenti si verificherebbero e quando si fermerebbero e ti impedirebbero di espandersi oltre 15 domini circa (troppi altri e ti avvicini pericolosamente al "limite di reindirizzamento" di molti browser e proxy).

Answer 2

Questa è una buona soluzione se hai il pieno controllo di tutti i backend dei domini. 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 :(.

Answer 3

L'esempio in questo articolo mi sembra sospetto perché sostanzialmente reindirizzi a un URL che, a sua volta, restituisce le variabili al tuo dominio in una stringa di querystring.

Nell'esempio, ciò significherebbe che un utente malintenzionato potrebbe semplicemente accedere a http: //slave.com/return.asp?Return=blah&UID=123 " ed essere registrato su slave.com come utente 123.

Mi sto perdendo qualcosa, o è noto che questa tecnica è insicura e non dovrebbe essere usata per, beh, cose come quelle suggerite dall'esempio (passare l'ID utente in giro, presumibilmente per rendere portatile la propria identità).

Answer 4

@thomasrutter

Potresti evitare di dover gestire tutti i collegamenti in uscita sui satelliti (aggiungendo "querystring" a querystring) effettuando una chiamata ajax per controllare lo stato di autenticazione sul caricamento della pagina nel dominio "centrale". È possibile evitare chiamate ridondanti (al successivo caricamento della pagina) effettuandone solo una per sessione.

Sarebbe probabilmente meglio effettuare la richiesta di verifica dell'autent 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 se l'utente è o meno ha effettuato l'accesso (e visualizza il contenuto di conseguenza).

Answer 5

Usiamo il concatenamento 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 "master" server che distribuisce i cookie / gestisce le interruzioni di accesso.

Nota che il tuo return.asp può essere abusato per reindirizzare a qualsiasi sito (vedi questo per esempio).

Answer 6

Ok, sembra che abbia trovato una soluzione, è possibile creare un tag di script che carica l'src del dominio su cui si desidera impostare / ottenere i cookie ... solo finora Safari sembra non essere in grado di impostare i cookie, ma Ie6 e FF funzionano bene ... comunque se vuoi solo ottenere i cookie, questo è un ottimo approccio.

Answer 7

Dovresti anche convalidare le informazioni della sessione attiva con i domini b, c, d, ... in questo modo puoi accedere solo se l'utente ha già effettuato l'accesso al dominio a.

Answer 8

Quello che fai è sul dominio che riceve le variabili che controlli anche sull'indirizzo del referrer in modo da poter confermare che il link proveniva dal tuo dominio e non che qualcuno semplicemente digitasse il link nella barra degli indirizzi. Questo approccio funziona bene.