2009-06-02 8 views
11

Mentre mi rendo conto che questo è solitamente correlato agli attacchi di cross site scripting, quello che mi chiedo è come una sessione può rimanere valida su più sottodomini appartenenti a un singolo dominio (esempio: un utente l'accesso solo una volta e l'accesso a entrambi i sottodomini1.dominio.com e sottodominio2.dominio.com con la stessa sessione). Immagino di dover prima capire come funziona, ma finora non sono stato in grado di trovare molto di pertinente.Accesso (o sessione) ai domini incrociati

Ma poi di nuovo, forse non stavo facendo la domanda giusta.

Grazie in anticipo :)

risposta

0

È possibile impostare un cookie per un dominio specifico.

In php, il metodo setCookie() contiene un parametro in cui è possibile specificare il dominio di primo livello, quindi il cookie è valido per tutti i sottodomini. In base ai tuoi tag, vedo che stai lavorando su asp.net. Probabilmente questo esiste anche per asp ...

dopo un po 'di ricerca per asp:

provare questo:

Response.Cookies("CookieName").Domain = ".mydomain.com" 

o leggere this

+0

Guarda il tag compagno. – Shoban

+1

euhm, l'ho fatto ... Altrimenti, non avrei scritto 'Basato sui tuoi tag' ... – Fortega

+0

Ma lo hai modificato di nuovo (?) Non vedo il secondo codice prima volta ;-) – Shoban

18

sessioni Inproc non può rimanere valida, tuttavia è possibile codifica la tua applicazione web per consentire i cookie su più sottodomini. Sarà necessario impostare il dominio pari a:

Response.Cookies("CookieName").Domain = ".mydomain.com" 

Remember the period.

+0

Non è possibile impostare i cookie in un altro dominio. Deve essere sotto il tuo dominio. – aleemb

+5

@aleemb, naturalmente, ho detto però i sottodomini. –

+17

Il titolo lo dice ma se leggi ciò che sta chiedendo, dice distintamente sottodomini. –

2

Per impostazione predefinita, tutti i cookie per un sito vengono memorizzate insieme sul client, e tutti i cookie vengono inviati al server con qualsiasi richiesta in tal luogo. In altre parole, ogni pagina di un sito ottiene tutti i cookie per quel sito. Tuttavia, è possibile impostare l'ambito dei cookie in due modi:

  1. Limitare l'ambito dei cookie a una cartella sul server, che consente di limitare i cookie a un'applicazione sul sito.
  2. Impostare l'ambito su un dominio, che consente di specificare quali sottodomini in un dominio possono accedere a un cookie.

Ulteriori informazioni: here.

1

I commenti sul cookie impostato per il dominio per consentire ai sottodomini di ricevere quel cookie ti danno quella parte ma quello che manca è la coerenza della sessione.

Penso che questo sia molto simile al problema di mantenere lo stato tra i server in una farm e la soluzione è probabilmente quella di garantire che lo store di sessione sia coerente su entrambi i siti (se non sono server dello stesso "sito web" in IIS). È possibile spostare l'archivio sessioni in SQL Server (HOW TO: Configure SQL Server to Store ASP.NET Session State) che probabilmente servirebbe allo scopo in quanto ogni sito eseguirà la query sullo stesso archivio quando si cercano i dati di sessione relativi al cookie con cui sono stati presentati.

Spero di metterti sulla buona strada.

6

Esistono diversi modi per condividere dati di sessione o dati cookie tra domini. Il più semplice è condividerlo dal lato server attraverso un archivio dati condiviso.Ma non faresti questa domanda se fosse così facile.

L'altro modo per farlo è altrettanto semplice. Il dominio one.com contiene alcuni dati di sessione che dicono name=aleem e id=123 e desidera passarlo a two.com. Sarà attenersi alla seguente procedura:

  1. effettuare una chiamata a two.com/api/?name=aleem&id=123
  2. Quando two.com ottiene i dati tramite parametri di query, si crea un cookie con i dati. Questo cookie verrà archiviato sotto il dominio two.com.
  3. two.com ridirigerà indietro alla REFERER che in questo caso risulta essere one.com

Questo è uno scenario semplificato. Il dominio two.com deve essere in grado di fidarsi di one.com e non solo, ma è necessario sapere che la richiesta è autentica e non solo creata dall'utente, quindi è necessario utilizzare chiavi pubbliche/private per mitigarlo.

1

Se avete la possibilità di impostare un sottodominio comune, si può fare questo:

nei file html sottodominio, includono un file javascript in alto in questo modo:

<script src="http: //common.domain.com/check.asp"></script> 

sotto controllo asp, cercare il cookie logged_in e se non presente, mostrare una pagina dire, http://common.domain.com/login.asp usando qualcosa come

<% 
if (cookie_not_found){ 
%> 
location.href = "http: //common.domain.com/login.asp"; 
<% 
} 
%> 

volta che una persona invia username password, presentare torna allo stesso login.asp e imposta il cookie di sessione, (che verrà impostato nel dominio common.domain.com) e quindi reindirizzare a http://subdomain1.domain.com.

Quello che succederà ora è che verrà effettuata una chiamata al "common.domain.com/check.asp" incorporato e i cookie per common.domain.com verranno inviati dal browser insieme alla richiesta. Quindi saprai se la tua sessione è valida o meno, anche quando ti trovi in ​​sottodominio1.dominio.com.

Problemi correlati