2012-03-17 11 views
9

Recentemente abbiamo lavorato a un'app web moderna e siamo pronti a implementarla per alpha/beta e ad acquisire un'esperienza del mondo reale.Hosting di contenuti statici su domini diversi dai servizi web, come evitare il cross-domain?

Abbiamo i servizi Web basati su ASP.Net (Web Api) e un front-end JavaScript che è 100% MVC lato client utilizzando backbone.

Abbiamo acquistato il nostro nome di dominio, e per il bene di questa domanda la nostra distribuzione si presenta in questo modo:

webservices.mydomain.com (Webservices)

mydomain.com (JavaScript front-end)

Se il JavaScript tenta di parlare con i servizi Web nel sottodominio, facciamo esplodere con problemi di dominio incrociato, ho giocato con CORS ma non sono soddisfatto del supporto cross-browser, quindi sto contando come un opzione.

Sul nostro PC di sviluppo abbiamo utilizzato un proxy inverso IIS per inoltrare tutte le richieste a mydomain.com/webservices a webservices.mydomain.com - Che risolve tutti i nostri problemi in quanto il browser pensa che tutto sia nello stesso dominio.

Quindi la mia domanda è, in una distribuzione pubblica, come viene risolto questo problema più comunemente? Un proxy inverso è il modo giusto per farlo? In tal caso, ci sono servizi in hosting che offrono un proxy inverso per questa situazione? Ci sono modi migliori per distribuire questo?

Voglio usare CloudFront CDN come tutti i nostri server/servizi sono ospitati su Amazon, sto davvero cercando di trovare informazioni su se un CDN in grado di supportare questo tipo di installazione però.

Grazie

+1

Forse la mia implementazione personale è troppo semplice (e se è così sarei interessato anche ai commenti degli altri). Immagino che cosa manca è il trasporto dei dati tra fronte/retro? Nella mia semplice implementazione, il front comunica con il back (servizio WCF) tramite JSONP per un'implementazione "reale" del dominio incrociato. Se ho bisogno di "proxy", allora è un "proxy app" - front su mydomain.com parlerà con un gestore (ad esempio ashx) su mydomain.com che "trasmette" la richiesta http a WCF su myotherdomain.com. – EdSF

+0

Stai usando JQuery o puro javascript? (nel caso di JQuery, è possibile utilizzare questo: http://usejquery.com/posts/the-jquery-cross-domain-ajax-guide) – ONOZ

+1

Per WebAPI, è possibile rivedere questo post abilitando CORS con JSONP che dovrebbe funzionare bene attraverso i browser http://goo.gl/KjT6y – cecilphillip

risposta

1

Ciò che si sta cercando di fare è chiamate cross-sottodominio, e non del tutto tra domini. Questi sono trucchi per questo: http://www.tomhoppe.com/index.php/2008/03/cross-sub-domain-javascript-ajax-iframe-etc/

Come chiesto come questo problema è più comunemente risolto. La mia risposta è: questo problema è comunemente EVITATO. Nel mondo reale dovresti configurare i tuoi domini, come ad esempio non devi fare in modo tale solo per far funzionare la tua applicazione o configurare un server proxy per inoltrare le chiamate per te. JSONP è anche una soluzione hack-ish.

+0

Per curiosità, come impostare i miei domini per evitare questo problema? Nella mia mente, le "applicazioni web" non sono ancora pronte per la prima serata, tuttavia non è ancora possibile creare ed eseguire un'applicazione web javascript pura. CORS = Bad support, JSONP = Funzionalità Hack/Limited, Inter-iframe coms = Hack. – Tyler

+0

È sufficiente impostare il servizio Web come mydomain.com/service con un servizio di bilanciamento del carico con proxy inverso e tutti i problemi sono scomparsi. – Tisho

0

È possibile utilizzare semplicemente JSONP per richieste AJAX, quindi il dominio incrociato non è un problema.

Se le richieste AJAX restituiscono un codice HTML, è possibile eseguire il escape in una stringa JSON.

Il secondo è un po 'imbarazzante, però.

0

Si hanno 2/3 strati

nel servizio Web classe code-behin, aggiungere questa atribute: <System.Web.Script.Services.ScriptService()> _

forse avete bisogno di aggiungere questo nel nodo System.web del web. config:

<webServices> 
     <protocols> 
      <add name="AnyHttpSoap"/> 
      <add name="HttpPost"/> 
      <add name="HttpGet"/> 
     </protocols> 
     </webServices> 

nell'interfaccia lato client

-Aggiungi riferimento web al servizio nel sottodominio (exmpl. webservices.mydomain.com/svc.asmx) studio visivo rendono la "classe proxy"

funzionalità -add nel del masterpage | di pagina | Codice di controllo behin -Semplicemente chiamare questa funzione dal lato client

È possibile utilizzare la funzionalità AJAX con scriptmanager o utilizzare un altro sistema come JQuery.

Se il sito Web principale è compilato in .NET 3.5 o precedente, è necessario aggiungere un riferimento allo spazio dei nomi System.Web.Extensions e dichiararlo nel file web.config.

0

Se si dispone della larghezza di banda (I/O di rete e CPU) per gestirlo, un proxy inverso è una soluzione eccellente. Un buon proxy inverso memorizzerà anche le chiamate statiche per aiutare a mitigare il ritardo della rete introdotto dal proxy.

L'altra opzione consiste nell'impostare i file di criteri e/o le intestazioni di criteri tra domini appropriati. Fare questo in alcuni fornitori di cloud può essere difficile o addirittura impossibile. Di recente ho riscontrato problemi con i file dei font e IE non era soddisfatto delle chiamate interdominio. Non è stato possibile ottenere il provider di archiviazione cloud che stavamo usando per impostare le intestazioni corrette, quindi le abbiamo ospitate localmente anziché dover gestire un proxy inverso.

1

Per consentire a questo servizio Web per essere chiamato da uno script, utilizzando ASP.NET AJAX, aggiungere la seguente riga al primo servizio web code-behind:

[System.Web.Script.Services.ScriptService] 
0

easyXDM è un plugin JavaScript croce di dominio che possono vale la pena esplorare. Fa uso di standard quando il browser li supporta e astrae i vari hack necessari quando il browser non supporta gli standard. Da easyXDM.net:

easyXDM è una libreria JavaScript che consente come sviluppatore per facilmente aggirare la limitazione messo in atto dalla stessa politica di origine , a sua volta, rendendo più semplice per comunicare ed esporre javascript API oltre i confini del dominio.

Al centro easyXDM fornisce uno stack di trasporto in grado di trasmettere messaggi in base stringa tra due finestre, un consumatore (principale documento) e un provider (incluso un documento utilizzando un iframe). Si tratta di utilizzando una delle varie tecniche disponibili, sempre selezionando quella più efficiente per il browser corrente. Per tutte le implementazioni , lo stack di trasporto offre la bidirezionalità, l'affidabilità , l'accodamento e la verifica del mittente.

Uno degli obiettivi di easyXDM è supportare tutti i browser che sono in uso comune e fornire le stesse funzionalità per tutti. Una delle strategie per raggiungere questo obiettivo è seguire gli standard definiti, più utilizzando il rilevamento delle funzioni per garantire l'uso del più efficiente.

Per citare autore facile di XDM:

... siti come LinkedIn, Twitter e Disqus così come le applicazioni vengono eseguite da Nokia e altri hanno costruito le loro applicazioni sulla parte superiore del quadro messaggistica fornito di easyXDM.

Quindi easyXDM non è chiaramente un po 'hacker, ma ammetto che è una grande dipendenza da portare avanti il ​​tuo progetto.

Lo stato corrente del Web è che se si desidera spingere la busta, è necessario utilizzare il rilevamento delle funzioni e il polyfill o semplicemente forzare gli utenti a eseguire l'aggiornamento a un browser HTML5. Se questo ti fa arrabbiare, non sei solo, ma i polifragi sono una specie di male temporaneo necessario per arrivare da dove il web è dove vorremmo che fosse.

Vedere anche this SO question.

Problemi correlati