Come una pagina Web può inviare un messaggio alla rete locale

Question

La nostra applicazione Web ha un pulsante che dovrebbe inviare dati a un server sulla rete locale che a sua volta stampa qualcosa su una stampante.

Finora è stato semplice: il pulsante ha attivato una richiesta AJAX POST a http://printerserver/print.php con un token, quella pagina connessa all'applicazione Web per verificare il token e ottenere i dati da stampare e quindi stampare.

Tuttavia, ora stiamo distribuendo la nostra applicazione Web tramite HTTP (e preferirei non tornare indietro a HTTP per questo) e le versioni più recenti di Chrome e Firefox non rendono più la richiesta all'indirizzo HTTP, non lo fanno t inviare anche la richiesta per verificare le intestazioni CORS.

Ora, qual è un'alternativa moderna al protocollo incrociato XHR? Websockets soffre dello stesso problema? (Una ricerca su Google non ha chiarito qual è lo stato attuale qui.) Posso usare già i socket TCP? Preferirei non passare alle richieste GET, perché l'azione non è idempotente e potrebbe avere implicazioni pratiche con il precaricamento e il caching.

posso cambiare l'applicazione sul Printerserver in alcun modo (così ho potuto sostituirlo con NodeJS o qualcosa del genere), ma non posso cambiare browser degli utenti (a fidarsi di un certificato auto-firmato per Printerserver per esempio).

Answer 1

È possibile memorizzare le richieste di stampa sul server Web in una coda e fare in modo che il server di stampa esegua periodicamente il polling delle richieste di stampa.

Se ciò non fosse possibile, installerei un tunnel o VPN tra il server web e le reti del server di stampa. In questo modo è possibile effettuare la richiesta di stampa dal server Web sul lato server anziché sul client. Se si usa curl, ci sono flag per ignorare i certificati SSL non validi, ecc. (Ho ancora il sospetto che sia più carino introdurre una coda comunque, quindi le richieste di stampa non si bloccano).

Se il server web può fare una connessione ssh a qualcosa sulla rete in cui il printserver è acceso, si potrebbe fare qualcosa di simile: ssh user @ host params qualche comando ricciolo qui.

Terza opzione a cui posso pensare, se il server di stampa può associare ad esempio un sottodominio del dominio del server web, come: print.somedomain.com, potresti essere in grado di renderlo affidabile con il certificato di somedomain.com, IIRC tu è necessario creare una CSR (Certificate Signing Request) dal certificato del server di stampa e firmarla con il certificato somedomain.com. Forse non ha nemmeno bisogno di essere un sottodominio per questo di per sé, ma forse è un requisito per il browser farlo sul lato client.

Answer 2

• Il server che ospita il webapp https può invertire proxy server di stampa, ma dal momento che la stampante è locale per l'utente, questo non può funzionare.

• Il server di stampa dovrebbe avere le corrette intestazioni CORS

  Access-Control-Allow-Origin: * 
  

  o:

  Access-Control-Allow-Origin: https://www.example.com 
  

Tuttavia there are pitfalls with using the wildcard.

Answer 3

Il modo più semplice è aggiungere una route alla webapp che non fa altro che inoltrare la richiesta al server di stampa.Quindi imposta la richiesta AJAX POST a https://myapp.com/print e l'accensione del codice sul lato server che effettua una richiesta a http://printerserver/print.php, con lo stesso contenuto POST ricevuto. Come ha detto @dnozay, questo è comunemente chiamato reverse proxy. Sì, per farlo dovrai riconfigurare il tuo printserver per accettare richieste (autenticate) dal server web.

In alternativa, è possibile passare il server di stampa a https e chiamarlo direttamente dal client.

Si noti che una connessione Web sicura (http) su una pagina sicura (https) probably non sarà uguale a work. E per una buona ragione: generalmente è una cattiva idea ingannare le persone creando connessioni insicure da quella che sembra loro una pagina sicura.

Answer 4

Da quello che ho capito dalla domanda, il server di stampa non è accessibile dall'applicazione Web, quindi la soluzione di proxy inverso non funzionerà qui.

L'utente non può effettuare richieste dal browser al server di stampa in base a criteri di origine incrociata.

Se si desidera comunicare con il server di stampa da una pagina HTTPS, è necessario che il server di stampa esponga print.php come HTTPS.

È possibile creare un record DNS A come sottodominio dell'applicazione Web che si risolve nell'indirizzo interno del server di stampa.

Con questi passaggi, dovresti essere in grado di aggiornare la tua pagina del server di stampa per rispondere con permissive intestazioni CORS che il browser dovrebbe quindi rispettare. Non penso che il browser possa emettere richieste CORS su diversi schemi di protocollo (HTTPS vs HTTP) o su domini interni, senza un TLD.