it-swarm.com.de

AJAX-Anforderungen von Phonegap Android App an HTTPS schlagen mit dem Status fehl

Ajax-HTTPS-Anforderungen von meiner PhoneGap/Cordova-App auf Android schlagen unerklärlicherweise mit Status = 0 fehl. Sie wird nur angezeigt, wenn Sie die App mit dem Freigabeschlüssel signieren (d. H. Beim Exportieren von ADT), jedoch nicht, wenn Sie mit dem Debug-Schlüssel signieren (direkt im Emulator oder Telefon ausgeführt).

request = new XMLHttpRequest()
request.open "GET", "https://some.domain/", true
request.onreadystatechange = ->
  console.log "** state = " + request.readyState
  if request.readyState is 4
      console.log "** status = " + request.status

request.send()

immer Ausgänge

** state = 4
** status = 0

Es spielt keine Rolle, ob ich die App über den Play Store oder mit dem Dienstprogramm adb installiere. Ich vermute, es könnte mit dem Zertifikat verbunden sein, da nicht alle HTTPS-Domänen auf diese Weise versagen.

13

Dies geschieht, wenn die angeforderte URL mit einem fehlerhaften oder selbstsignierten Zertifikat antwortet. Beim Testen oder Verteilen der App an Freunde ist die Einstellung von <application Android:debuggable="true"...> in AndroidManifest.xml ausreichend - es werden Zertifikatsfehler automatisch umgangen.

Der Google Play Store akzeptiert jedoch keine APK mit Android:debuggable="true". Zunächst müssen die Zertifikate natürlich repariert werden. Während dies passiert, ist hier eine Problemumgehung für PhoneGap/Cordova 3:

  1. Erstellen Sie in Ihrem App-Paket eine Unterklasse für CordovaWebViewClient:

    public class SSLAcceptingCordovaWebViewClient extends CordovaWebViewClient {
        public SSLAcceptingCordovaWebViewClient(CordovaInterface cordova, CordovaWebView view) {
            super(cordova, view);
        }
    
        @Override
        public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
            handler.proceed();
        }
    }
    
  2. Gleiches für IceCreamCordovaWebViewClient:

    public class SSLAcceptingIceCreamCordovaWebViewClient extends IceCreamCordovaWebViewClient {
        public SSLAcceptingIceCreamCordovaWebViewClient(CordovaInterface cordova, CordovaWebView view) {
            super(cordova, view);
        }
    
        @Override
        public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {
            handler.proceed();
        }
    }
    
  3. in <Your App Name>.Java eine Überschreibung für makeWebViewClient hinzufügen:

    @Override
    protected CordovaWebViewClient makeWebViewClient(CordovaWebView webView) {
        if(Android.os.Build.VERSION.SDK_INT < Android.os.Build.VERSION_CODES.HONEYCOMB) {
            return new SSLAcceptingCordovaWebViewClient(this, webView);
        } else {
            return new SSLAcceptingIceCreamCordovaWebViewClient(this, webView);
        }
    }
    

Et voilà! SSL-Fehler werden nicht berücksichtigt. Verwenden Sie jedoch niemals fehlerhafte Zertifikate. Versuchen Sie, sie zuerst zu beheben, und verwenden Sie diese schmutzige Problemumgehung nur, wenn andere Lösungen ausgehen.

6

Ich hatte das gleiche Problem, aber meine Lösung war etwas anders. 

  1. Nur bei der Android-App-Erstellung meiner Cordova-App wurden AJAX -Anrufe an meinen Server über HTTPS blockiert. Nicht in iOS, nicht in Desktop-Browsern. Am verwirrendsten ist, dass im eigentlichen Android-Browser die HTTPS AJAX-Aufrufe kein Problem darstellen.

  2. Ich habe bestätigt, dass ich HTTPS AJAX -Aufrufe an bekannte und vertrauenswürdige URLs wie https://google.com sowie reguläre HTTP-Aufrufe an alle URLs durchführen kann, die ich versuchen wollte.

  3. Dies brachte mich zu der Annahme, dass mein SSL-Zertifikat entweder NICHT zu 100% NICHT korrekt installiert war OR das billige (~ 10 USD) -Zertifikat von PositveSSL war nicht allgemein vertraut OR.

  4. Mein Zertifikat wurde auf meinem AWS Load Balancer installiert. Ich habe mich also umgesehen, wie ich dies vermasselt habe und wie positivSSL nicht das beste Zertifikat ist, das in Bezug auf Vertrauenswürdigkeit verwendet werden kann. Zum Glück fand ich einen Artikel über die Installation von AWS ELB-Zertifikaten UND sie haben zufällig ein PositiveSSL-Zertifikat verwendet! Darin enthalten war dieses kleine Juwel: 

"... Lassen Sie sich nicht vom AWS-Dialog täuschen, die Zertifikatskette ist nicht wirklich optional, wenn Ihre ELB direkt mit einem Browser spricht ..."

http://www.nczonline.net/blog/2012/08/15/setting-up-ssl-on-an-Amazon-elastic-load-balancer/

Trommelrolle ....

Ich habe das cert mit der "optionalen" Certificate Chain-Info und voilà! Neu installiert. Die HTTPS AJAX -Anrufe an meinen Server funktionierten.  

Es scheint also, dass der Android-Webview in Bezug auf das Vertrauen von cert konservativer ist als der Android-Browser. Dies ist nicht völlig intuitiv, da es sich im Wesentlichen um dieselbe Technologie handeln soll.

13

Die andere Option, die ebenfalls funktioniert, besteht darin, die darunterliegende Datei cordova.jar neu zu kompilieren, sodass der Test vollständig entfernt wird. Es besteht also kein Grund, sich um die Gültigkeit des Zertifikats zu sorgen. Ich lief in der Ausgabe, weil Android das GoDaddy-Zertifikat, das sich auf dem Server befand, nicht erkennen konnte. Das Zertifikat zeigt sich auf iOS gültig, aber auch beim Browsen über Android beschwert sich das Zertifikat. Dies ist aus dem Zweig 2.9.x, da ich damit gearbeitet habe.

cordova-Android/Framework/src/org/Apache/Cordova/CordovaWebViewClient.Java

@TargetApi(8)
@Override
public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) {

    final String packageName = this.cordova.getActivity().getPackageName();
    final PackageManager pm = this.cordova.getActivity().getPackageManager();

    ApplicationInfo appInfo;
    try {
        appInfo = pm.getApplicationInfo(packageName, PackageManager.GET_META_DATA);
        handler.proceed();
        return;

        /* REMOVED TO BY PASS INVALID CERT CHAIN ****
        if ((appInfo.flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0) {
            // debug = true
            handler.proceed();
            return;
        } else {
            // debug = false
            super.onReceivedSslError(view, handler, error);
        }*/
    } catch (NameNotFoundException e) {
        // When it doubt, lock it out!
        super.onReceivedSslError(view, handler, error);
    }
}

ANMERKUNG: Ich verstehe, dass dies nicht sicher ist, aber wenn alles andere fehlschlägt, wurde das Problem behoben, das seit über 2 Monaten bestand, einschließlich der Neuinstallation des Zertifikats gemäß der Installationsanleitung für die Zertifizierungskette. Daneben befindet sich eine Website, die nicht von einem Drittanbieter stammt Egal ob gültig oder nicht, es wird nur eine Verbindung zu diesem Server hergestellt.

4
sneighbors

In meinem Fall war es ein fehlendes Zwischenzertifikat, das ich auf meinem Webserver installieren musste. Sie müssen dies besonders berücksichtigen, wenn Sie billige Zertifikate verwenden. 

Sie können es einfach online überprüfen, wenn Ihre Zertifikatskette korrekt ist. Sie finden eine Menge bei Google, z. https://www.sslshopper.com/ssl-checker.html

Beim Apache2 ist er Teil der VirtualHost 443-Direktive. In Ihrer Direktive gibt es drei Regeln. Sieht so aus:

SSLCertificateFile    /etc/Apache2/ssl/mycert.crt

SSLCertificateKeyFile /etc/Apache2/ssl/mykey.key

SSLCertificateChainFile  /etc/Apache2/ssl/certification_auth_intermediate.crt
1
Kim Michael

Sie können relse-ready (phonegap) -Paps nicht mit selbstsignierten Zertifikaten verwenden. Schauen Sie sich diese Antwort an, um weitere Informationen zu erhalten.

lg

fastrde

0
fastr.de