3 messaggi dal 03 aprile 2011
Buongiorno,

Ho un servizio windows (un'applicazione c# basata su HttpListener) in ascolto sulla porta http://127.0.0.1:8161 e un sito web che effettua una chiamata ajax verso questo indirizzo.
Attualmente la comunicazione ajax funziona se la richiesta che parte viene dal sito pubblicato in HTTP.

Quando il sito è pubblicato in HTTPS la richiesta non funziona.
(o meglio: su Chrome la richiesta parte se forzo la chiamata va verso HTTP://127.0.0.1:8161
su Firefox ed IE 10 non funziona)




Ho indagato sul problema: quello che dovrei fare è una richiesta di tipo CORS (cross-domain)
perchè la richiesta parte da un dominio.it e va verso localhost che appartengono a domini diversi.
Però anche attivando l'opzione CORS : true sulla chiamata jquery ajax la richiesta non va a buon fine.

Debuggando con Fiddler ho visto che viene lanciata un'eccezione di tipo System.IO.Exception Sincronizzazione non riuscita, il pacchetto è in un formato non previsto.
(il pacchetto che genera questo errore è un'inizializzazione di comunicazione SSL)

Ho scoperto di dover associare un certificato sulla porta dove il servizio è in ascolto.
Seguendo una guida per creare un certificato autofirmato (https://www.codeproject.com/Articles/24027/SSL-with-Self-hosted-WCF-Service) sono riuscito nell'intento.

In questo caso, avviando il servizio in ascolto su https://127.0.0.1:8161 e debuggando ancora una volta con fiddler vedo che c'è una risposta corretta al pacchetto di handshake SSL
ma alla successiva richiesta di tipo OPTION viene risposto "Method not allowed".
Creando un pacchetto apposta per effettuare una chiamata POST (cosa fatta in automatico da Firefox)
mi viene risposto "Method not found".



Ho un po di domande:
1- una comunicazione HTTPS di questo genere è fattibile?
2- questo tipo di comunicazione js <--> c# è sicuro?
3- installando questo client su tanti terminali devo generare un certificato unico per ogni macchina?
4- nel caso sia possibile questa soluzione vanno bene dei certificati autofirmati da associare alla porta del programma?
5- Esiste un metodo alternativo di comunicazione che non richieda la creazione di certificati?

Grazie mille
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


vedo che c'è una risposta corretta al pacchetto di handshake SSL
ma alla successiva richiesta di tipo OPTION viene risposto "Method not allowed".

Sì, inviare una richiesta di tipo OPTION è il normale comportamento di un browser quando deve inviare una richiesta Ajax ad un altro dominio (CORS: Cross-Origin Resource Sharing).
Il browser, in pratica, vuol sapere dal server se il dominio di origine è autorizzato a rivolgergli richieste Ajax oppure no. Il server deve rispondere in maniera appropriata ma nel tuo caso sta proprio rifiutando la richiesta con questo errore:

Method not allowed


Dev'essere che il tuo servizio è configurato per ricevere solo richieste di tipo GET e POST.
Vedi se questa discussione ti è d'aiuto:
https://stackoverflow.com/questions/25437405/cors-access-for-httplistener
Non leggere la risposta accettata ma vai all'ultima in fondo.



1- una comunicazione HTTPS di questo genere è fattibile?

Sì, non dovrebbero esserci problemi. Hai detto che il servizio è in ascolto su "http://127.0.0.1:8161". Vuoi dire che l'hai configurato solo su localhost e quindi non è possibile accedere al servizio dall'esterno della macchina? Se è questo il caso, perché ti è necessario un certificato SSL? Si presuppone che la comunicazione sia al sicuro fintanto che i pacchetti non escono dalla macchina.


2- questo tipo di comunicazione js <--> c# è sicuro?

A questo non è possibile rispondere. Dipende da come lo usi. E' come dire: "un coltellino svizzero è sicuro?". La risposta potrebbe essere: "Non se punti la lama verso di te".
Per esempio, inviando numeri di carta di credito su internet con connessione non sicura ti esponi a furti di dati a prescindere dalla tecnologia usata.


3- installando questo client su tanti terminali devo generare un certificato unico per ogni macchina?

No, dato che il certificato si installa lato server ti basterà giusto un certificato.

4- nel caso sia possibile questa soluzione vanno bene dei certificati autofirmati da associare alla porta del programma?

No, da quando esiste Let's Encrypt è quasi inutile autofirmarli. Let's Encrypt ti permette di ottenere un certificato SSL da una certification authority riconosciuta e puoi fare tutto in maniera gratuita e automatizzata con un tool da riga di comando. Leggi qua la documentazione:
https://letsencrypt.org/docs/
Fai un tentativo, veri se riesci ad allacciarlo al tuo servizio. In alternativa al servizio per Windows hai valutato se realizzare un sito web ASP.NET con WCF?



5- Esiste un metodo alternativo di comunicazione che non richieda la creazione di certificati?

Http semplice, senza certificato, ma solo se i pacchetti restano nella macchina o al limite nella rete locale della tua azienda dove, si presuppone, non esistano persone intenzionate a rubare dati.

ciao,
Moreno
Modificato da BrightSoul il 09 febbraio 2018 19.57 -

Enjoy learning and just keep making
3 messaggi dal 03 aprile 2011
Grazie per la risposta!

Dev'essere che il tuo servizio è configurato per ricevere solo richieste di tipo GET e POST.
Vedi se questa discussione ti è d'aiuto:
https://stackoverflow.com/questions/25437405/cors-access-for-httplistener


Provo a vedere se usando queste opzioni viene effettuata la comunicazione.

Mi sai indicare una guida per creare velocemente un sito web ASP.NET su HTTPS con IIS Express?

Hai detto che il servizio è in ascolto su "http://127.0.0.1:8161".
Vuoi dire che l'hai configurato solo su localhost e quindi non è possibile accedere al servizio
dall'esterno della macchina? Se è questo il caso, perché ti è necessario un certificato SSL?


La chiamata ajax da https://dominio.it verso http://localhost:8161 funziona praticamente solo in Chrome.
In Firefox ed IE la richiesta viene bloccata
(con Chrome e Firefox all'handshake dell'SSL viene data come risposta l'eccezione che dicevo;
In IE la richiesta ajax va subito in fail senza neanche tentare la connessione).

Visto che la comunicazione dovrebbe andare per questi 3 browser e la chiamata deve rispettare
la Same Origin Policy ho pensato che anche il servizio deve essere raggiungibile su HTTPS.
Da qui la necessità di usare i certificati per la connessione SSL.

Usando i certificati c'è la prima parte di comunicazione anche per Firefox
(in IE mi da ancora problemi, credo per le impostazioni di Security Zones)

In alternativa al servizio per Windows hai valutato se realizzare un sito web ASP.NET con WCF?


Purtroppo è tutto già strutturato come servizio windows e non posso cambiarlo.
Questo va a leggere dei file sul terminale utente che poi passa come configurazione al sito web.


Grazie mille
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


ho pensato che anche il servizio deve essere raggiungibile su HTTPS.

HTTPS non è necessario per abilitare CORS lato servizio. HTTPS ti serve se vuoi che la comunicazione tra client e server sia sicura. Fai così: prima concentrati nel risolvere CORS seguendo le istruzioni del link che ti ho mandato e poi (se necessario) vedi come supportare HTTPS.


Mi sai indicare una guida per creare velocemente un sito web ASP.NET su HTTPS con IIS Express?

Non penso ti serva un sito IIS, hai già detto che è stato tutto impostato su servizio per Windows.


La chiamata ajax da https://dominio.it verso http://localhost:8161

Continuo a chiedermi come possa funzionare usando localhost. Supponi che sia io, dal mio PC, a visitare il tuo sito http://dominio.it. Riesco a vedere le pagine perché questo sito è pubblicato su internet.
Nel momento in cui quel sito tenta di inviare una richiesta Ajax verso http://localhost:8161, fallirà immediatamente perché il nome "localhost" identifica il mio PC, e non il tuo server. Il nome "localhost" si risolve con l'ip 127.0.0.1 che identifica il mio portatile e lì non c'è alcun servizio in ascolto sulla porta 8161.
Quindi, come fanno gli utenti a raggiungere il servizio? Hai predisposto un nome host differente da "localhost"?

ciao e buon weekend!
Moreno
Modificato da BrightSoul il 10 febbraio 2018 15.02 -

Enjoy learning and just keep making
3 messaggi dal 03 aprile 2011
Ciao,
grazie per le risposte.

Purtroppo attulamente non ho più in carico questo problema ma volevo comunque rispondere.

Continuo a chiedermi come possa funzionare usando localhost.


Non ti ho chiarito correttamente come è architettata la comunicazione:
- il terminale-pc dell'utente che visita il sito web ha il servizio windows installato sulla sua macchina che inizializza un listener su http://127.0.0.1:8161.
- il browser manda le richieste sulla suddetta porta


HTTPS non è necessario per abilitare CORS lato servizio. HTTPS ti serve se vuoi che la comunicazione tra client e server sia sicura.


Ho provato più volte a mandare la richiesta HTTPS verso il servizio in ascolto su HTTP ma fallisce con l'errore del formato pacchetto non previsto.

Purtroppo non sono riuscito a provare ad usare i parametri che mi hai suggerito su stackoverflow senza ottenere l'errore.

Hai disponibile/ puoi indicarmi delle guide per capire come impostare questo tipo di comunicazione?

Ti ringrazio
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,


il terminale-pc dell'utente che visita il sito web ha il servizio windows installato sulla sua macchina

Aaaaaah, ok. Quindi sì, in questo caso sarebbe necessario procurarsi un certificato SSL per ogni installazione del servizio. Dato che ogni client agisce anche da server per sé stesso, ti servirà installare il certificato su ogni macchina client.

Direi che HTTPS non è necessario perché le richieste sono rivolte alla macchina locale, quindi puoi tralasciare.


Ho provato più volte a mandare la richiesta HTTPS verso il servizio in ascolto su HTTP ma fallisce con l'errore del formato pacchetto non previsto.

Vai in HTTP, non è necessario che la comunicazione sia sicura.

ciao,
Moreno

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.