Come impedire a un'applicazione Meteor/Cordova di connettersi a 10.0.2.2? (E perché l'app si collega lì?)

Question

Ho un'app Meteor che gira su un server locale per lo sviluppo (http://10.0.2.10:3000). ROOT_URL è impostato correttamente, pertanto __meteor_runtime_config__.ROOT_URL è uguale a questo URL. Ovviamente l'app funziona perfettamente nel browser su un computer client entro 10.0.2.0/24. L'app funziona perfettamente anche su Chrome/Firefox mobile sul mio cellulare Android, anch'esso parte di 10.0.2.0/24. Tuttavia quando provo a eseguirlo come app su questo cellulare con meteor run android-device --mobile-server http://10.0.2.10:3000/ succede qualcosa di strano:

Quando l'app si avvia per la prima volta (o la prima volta dopo che ho cancellato tutti i dati dell'app) funziona come dovrebbe (contenuto dal DB è caricato) per pochi secondi. Quindi l'app si ricarica e qualsiasi contenuto remoto dal DB non viene più caricato. Ho aggiunto la seguente funzione per vedere dove Meteor tenta di connettersi a:

Meteor.startup(function(){ 
    console.log(__meteor_runtime_config__.ROOT_URL); 
}) 

La prima volta quando il contenuto viene caricato remoto restituisce http://10.0.2.10:3000/ come mi sarei aspettato. La seconda volta che il contenuto remoto non viene caricato restituisce http://10.0.2.2:3000/.

La domanda ora è, perché Meteor/Cordova sta facendo questo e come posso interrompere questo comportamento? Perché ovviamente non posso testare l'app in questo modo. Non sono ancora sicuro se funzionerebbe in produzione quando ho un proxy FQDN e HTTPS ma questo è oltre il punto.

ho cercato di trovare 10.0.2.2 come nulla nella mia LAN è in esecuzione lì e non ho specificato questo IP ovunque e lo abbiamo trovato in /cordova-build/www/application/index.html che sembra essere generato da boilerplate_web.cordova.html (si veda questo link https://searchcode.com/codesearch/view/91819963/). Tuttavia Meteor offre la possibilità di ignorare questi file generati con una cartella cordova-build-override e così ho fatto rimuovere l'intero

if (/Android/i.test(navigator.userAgent)) { 
    //[...] 
} 

blocco e ha aggiunto un breve console.log('removed'). Questo viene chiamato così so che l'override ha avuto successo e quando non ho trovato l'intero file .apk costruito 10.0.2.2 non viene più trovato - il comportamento è sempre lo stesso.

Qualche idea cosa sta succedendo e cosa fare?

Answer 1

Quindi, anche quando si imposta il ROOT_URL correttamente, esistono ancora variabili speciali per le versioni mobili che non vengono impostate e possono contenere localhost. E sembrano esserci più frammenti di codice nel progetto meteor che sostituisce localhost con 10.0.2.2 oltre a quello che ho menzionato sopra, quando un client Cordova si sta connettendo. In questo modo sembra che la mia app si ricolleghi a 10.0.2.2.

Le variabili URL per dispositivi mobili che ho trovato sono process.env.MOBILE_ROOT_URL e process.env.MOBILE_DDP_URL. Quindi in una funzione Meteor.startup() ora li ho impostati sul mio reale ROOT_URL sul lato server. La mia app Android (Cordova) ora si sta ancora ricollegando pochi secondi dopo il suo primo avvio, ma si sta ricollegando allo stesso (e vero) URL del server (quindi tutto funziona correttamente)!

Ancora non so perché la sua riconnessione e quelle variabili mobili e il loro uso non sembrano essere molto ben documentati (o mi sono perso qualcosa) ma posso vivere con il modo in cui le cose funzionano ora.