È richiesto CORS per integrare un servizio REST con un'applicazione web?

Question

È richiesto CORS per integrare un servizio REST con un'applicazione web?

#1 da (3 voti)
#2 da (0 voti)

2

Ho quel servizio di messaggistica RESTful self-hosted con autorizzazione, SSL e altro materiale utile che lo accompagna. Ora, mi piacerebbe consumare quel servizio, quindi ho bisogno di un'interfaccia utente. Solitamente (per il bene multipiattaforma) tendo a sviluppare un'applicazione web ASP.NET MVC, ma questa volta non sono sicuro di come procedere.

Tuttavia, ho alcune idee:

Se ci sono due applicazioni disaccoppiate - un'applicazione web e un servizio REST - ci deve essere CORS abilitato sul client.
Se esiste un'applicazione Web che utilizza in qualche modo un proxy (forwarder?) per accedere al servizio REST, non ho bisogno di CORS. Ma non so come esattamente ciò dovrebbe essere fatto in MVC.

Un'altra cosa: preferirei che fosse disaccoppiato, quindi non voglio che una terza opzione sia di riempire entrambe le cose in un unico sacco.

Sono un po 'deluso da ciò che Google dice sull'argomento. Dovrebbero esserci ovviamente più informazioni, o non so come cercarle.

Le mie domande sono:

Devo andare con la scelta n. 1 o n. 2?
A proposito della scelta n. 2, è pratico e c'è una soluzione per le migliori pratiche?
C'è una terza scelta che mi manca qui?

rest asp.net-mvc

posta OzrenTkalcecKrznaric 01.01.2017 - 15:14

fonte

2 risposte

0

CORS non è richiesto in nessun caso. Ma incorporare elementi aggiuntivi come proxy al posto di uno standard ben definito e un approccio come CORS è una violazione di < a href="https://www.wikiwand.com/it/Occam%27s_razor"> Il rasoio di Occam e KISS principio IMHO. Questo è il motivo per cui vorrei seguire con CORS se fossi in te. I REST servizi web sono, per design, disaccoppiati dai suoi clienti, quindi la terza opzione che stai considerando è fuori discussione qui . Hai menzionato che il servizio che stai per consumare è protetto da qualche livello di autorizzazione e autenticazione. Supponendo che sia stato progettato per essere pubblicamente disponibile in mente, ed è già protetto da un ulteriore livello di autenticazione e autorizzazione, allora puoi semplicemente utilizzare l'approccio criterio della stessa origine dell'origine :

A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site. — Wikipedia

risposta data 01.01.2017 - 17:07

fonte

Leggi altre domande sui tag rest asp.net-mvc

Come usi le librerie esterne in git? Richiedi dati da Wikidata ogni volta o salvalo nel database?

score 3 · Accepted Answer

È necessario CORS solo se il client per il servizio REST si trova all'interno del browser (ad esempio una SPA, ad esempio) e solo se il client si trova in un dominio diverso da quello del servizio REST.

Se la tua applicazione web è il client o se l'applicazione web è solo un proxy per il servizio REST, allora non hai bisogno di CORS.

Ora, la scelta di una soluzione dipende molto dal problema che stai cercando di risolvere. Come hai fatto, ci sono 3 possibili soluzioni:

Avere una SPA che si connette direttamente al servizio REST. Hai bisogno di CORS per questo se hai la SPA su un dominio diverso (una SPA viene fornita con altre questioni troppo). Si potrebbe evitare l'uso di CORS se si dispone di SPA su www.domain.com/app e il servizio REST esposto come www.domain.com/api ad esempio, ma puoi avere solo un client in questo modo.
Avere di nuovo una SPA, ma distribuita da un'applicazione Web che utilizza il servizio REST. Per l'utilizzo di un'applicazione Web come proxy in questo modo non è necessario CORS perché ci si trova nello stesso dominio. Fondamentalmente si ricreano le operazioni HTTP nell'applicazione MVC Asp.NET (beh ... non sarà MVC dato che si avrà solo il controller).
Avere una classica applicazione Web che si connette al servizio REST e serve le pagine laterali del server alle richieste del browser client. Qui hai un'app completa di Asp.NET MVC, con l'accesso al servizio REST molto probabilmente come repository di qualche tipo.

Come ho detto, la scelta dipende dal problema che stai cercando di risolvere. Pensa bene prima di scegliere perché tornare indietro e farlo di nuovo, in un altro modo, potrebbe essere davvero doloroso.