MOB: iOS Httpreq e server https.

[mromini]

Ciao a tutti. Avrei la necessità di interagire da iPad con dei server https con certificato auto generato. Per far funzionare la httpreq ho aggiunto al file Xmldocument.m le seguenti righe:

//Gestione certificato SSL autogenerato
- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust];
}

- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
[challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
}
//Gestione certificato SSL autogenerato

Con la versione 12.5 di IN.DE e relativo template iOS la modifica funzionava correttamente. Passato alla 13.1 ho riportato la modifica nel template aggiornato ma sembra non funzionare più.

Qualche idea?

[lucabaldini]

E' dovuto al fatto che in 13.1 abbiamo cambiato il modo in cui vengono effettuate la chiamate HTTP.

Provo a riepilogare velocemente quel che è successo.

Quando è nata la shell nativa avevamo necessità di far comunicare lo strato WEB delle nostre applicazioni con la porzione nativa della shell. La comunicazione inversa (shell nativa -> WEB) era già presente e perfettamente funzionante.

In iOS5 (quando è nata Caravel e la shell nativa) non esisteva alcun modo "naturale" per garantire questo collegamento. Phonegap e altri utilizzavano il cambio URL degli iFRAME ma con molti problemi. Noi abbiamo scelto di attivare un vero e proprio canale HTTP tra il web e la shell nativa. Praticamente se la parte web deve inviare un messaggio alla shell nativa effettua una chiamata HTTP ad un particolare URL che la shell nativa ascolta.

Tutto questo funzionava correttamente fino a quando è arrivato iOS6. In iOS6 era ancora possibile ascoltare chiamate HTTP provenienti dalle webView ma non era possibile, all'interno di quella richiesta (quindi in maniera sincrona) effettuare, a sua volta, chiamate sincrone HTTP. Quindi, per fare un esempio, non funzionava più la DownloadFile sincrona.

Per risolvere il problema in iOS6 abbiamo scoperto che le chiamate sincrone non funzionavano più con iOS6 ma le chiamate asincrone sì. Quindi abbiamo cambiato tutte le chiamate HTTP eseguite durante una chiamata dalla parte web dell'app in chiamate asincrone sincronizzate. E tutto è tornato a funzionare correttamente.

[lucabaldini]

Poi è uscito iOS 7 e, questa volta, non andavano né le chiamate HTTP sincrone né le chiamate HTTP asincrone.

Non c'era soluzione... abbiamo quindi scelto di utilizzare, per fare chiamate HTTP, una libreria di terze parti. Tale soluzione non era soddisfacente (passare da una libreria ad un'altra è sempre un rischio... si sa quel che si lascia e non si sa mai quel che si trova!).

Quindi abbiamo aperto un ticket su Apple (uno dei 2 concessi all'anno!!).
Dopo aver contattato Apple ed aver parlato con un loro programmatore ci hanno suggerito di cambiare metodo di comunicazione web-shell utilizzando i custom protocol (classe NSURLProtocol).

Ora, in 13.1 abbiamo seguito il consiglio dello sviluppatore Apple ed abbiamo utilizzato gli NSURLProtocol. Ora era di nuovo possibile fare chiamate HTTP sincrone durante una chiamata proveniente dalla shell nativa.... quindi abbiamo ripristinato il codice a come era in iOS5, ovvero utilizzando il metodo nativo

[NSURLConnection sendSynchronousRequest:request returningResponse:response error:error];

Questo è il motivo non riesci più a by-passare la chiamata forzando l'uso di certificati invalidi.

Purtroppo non credo sia più possibile fare quel che stai facendo dato che in iOS7 non è più possibile fare chiamate asincrone durante una chiamata proveniente dalla shell nativa... e solo per le chiamate asincrone credo sia aggirabile la gestione del certificato...

[lucabaldini]

Purtroppo uno dei problemi della soluzione NSURLProtocol è che non funzionano le chiamate asincrone-sincronizzate durante la gestione del custom protocol. In altre parole, in quel caso, la chiamata deve per forza essere sincrona... e, per quel che ne so io, non è possibile forzare l'uso di certificati invalidi durante una chiamata sincrona.

Ovviamente non sono sicuro di questo... bisognerebbe cercare su internet per capire come si possa fare una chiamata sincrona (riga 436 di XMLDocument.m)

[NSURLConnection sendSynchronousRequest:request returningResponse:response error:error];

con certificati invalidi (auto-generati).

[mromini]

Ciao Luca, grazie per la risposta molto dettagliata.
Cercando su Internet ho trovato questa soluzione (http://www.cnblogs.com/gnorts/p/3525144.html):

Before the @implementation of your http client, you could add the following code:

@interface NSURLRequest (IgnoreSSL)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host;
@end

@implementation NSURLRequest (IgnoreSSL)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString*)host
{
return YES;
}
@end

This replacement method gets automatically called and you can decide based on the host to allow any certificates or not.
Alternatively you can always return YES regardless of the host parameter to ignore all invalid certificates.

Ho inserito il codice nel file Xmldocument.m e dopo aver fatto qualche prova veloce e mi sembra funzionare.

Ciao,
Mario.