In che modo Delphi XE2 può comunicare con le API di Google Calendar su SSL?

Question

È il momento di this question di nuovo, ma questa volta con Delphi XE2.

Sto usando la versione 10.5.8.0 Indy che le navi con XE2, e ho provato quattro diverse versioni delle DLL SSL. Ho provato l'ultima versione 1.0.xe circa 3 diverse versioni 0.9.8 (e, h, x, ....).

Nessuno di questi funziona quando si comunica a https: // urls su calendar.google.com. L'autore del componente Google Calendar di Delphi a "Sync-components.com" invia il proprio binario openssl di runtime DLL che non contengono informazioni sulla versione, ma sembra essere una versione molto piccola e molto vecchia di librerie SSL precedenti alla 0.9.8. L'autore del componente dice che solo le sue DLL private non controllate funzionano. Non posso crederci. Sicuramente almeno una versione di dll openSSL funziona abbastanza bene con Delphi XE2 per connettersi a Google Calendar.

Al fine di ottenere la sua antica usanza DLL caricare nella Indy 10 in Delphi XE2, egli modifica il metodo IdSSLOpenHeaders.pas carico, in questo modo, alla fine:

function Load: Boolean; 
begin 
    /// ... lots of stuff 
    //Result := (FFailedFunctionLoadList.Count = 0); // original. 
    Result := (FFailedFunctionLoadList.Count <= 18); // changed to. 
end; 

Naturalmente, il componente che ho sto valutando non funziona in XE2, ma ho il sospetto che sia la rottura di entrambi (a) questa particolare istantanea di Indy 10 che viene fornito con XE2, o (b) il fatto che il mondo delle DLL SSL sia un vero inferno di "rotto per tu lavori per me "versioni differenti.

Cosa devo fare per ottenere una connessione SSL a Google Calendar, utilizzando Indy (o qualsiasi altra libreria di componenti delphi con supporto SSL), in Delphi XE2?

In alternativa, se qualcuno ha un'implementazione API di Google Calendar che funziona con qualcosa di diverso Indy che potrei usare per i test, le sarei grato link e puntatori.

Answer 1

C'è qualcosa di sbagliato nell'istantanea di Indy10 fornita con XE2, in quanto l'oggetto idHTTP sembra non funzionare bene con nessuna delle DLL OpenSSL che ho trovato, in quanto non potevo comunicare con nessun servizio di server di Google Calendar con loro.

La natura stessa base del problema sembra essere che Indy non gestisce HTTP riorienta più trasparente avremmo sperato. Il codice che sta manipolando Indy (componente di terze parti) rende davvero difficile capire le cose con la logica di gestione dell'indirizzamento "http redirect" che sembra essere un insieme di soluzioni alternative che non funzionano. Inoltre, la confusione è che i luoghi esatti nel codice in cui si verificano i reindirizzamenti HTTP variano da una persona che esegue il test di Google Calendar, a un altro, quindi questi errori di reindirizzamento non sempre appaiono negli stessi luoghi per ogni persona che lo esegue.

Si noti che il metodo di accesso e il metodo per far funzionare i calendari. Ma i metodi e il codice che dovevano leggere gli eventi, sembrano non funzionare. Non sono stato in grado di capire la differenza tra i due, ma il codice che sto usando è commerciale e non posso pubblicare nulla di ciò. Vi aggiornerò questo messaggio se mai a capire la ragione tecnica effettivo che la richiesta HTTP get stava tornando "0 byte" nella sua risposta per gli URL come questo:

https://www.google.com/calendar/feeds/firstname.lastname%40gmail.com/private/full?max-results=100000 

Quei risultati pari a zero byte sono stati davvero HTTP 302 risposta di reindirizzamento codice, che il codice che stavo usando, non ha verificato o previsto. Si aspettava che Indy gestisse automaticamente i reindirizzamenti.

Il problema potrebbe essere che la versione Indy10 è molto specifica e funziona solo con una versione delle DLL openSSL che non ho trovato nella mia ricerca odierna, o che la versione Indy10 fornita con XE2 non funziona con QUALSIASI versione delle DLL OpenSSL che ho trovato, almeno non quando il target con cui si sta parlando è il server di calendario HTTPS di google.

Il codice che sto eseguendo crea un oggetto IdHTTP con un TIdSSLIOHandlerSocketOpenSSL.

Questo funziona in tutte le versioni di Delphi fino a XE incluso, ma si interrompe con un sistema XE2 di fabbrica, a causa della versione di Indy fornita con XE2.

L'unica correzione che ho trovato è installare una nuova build notturna di Indy, ho preso 4760, che sembra funzionare bene, se combinato con OpenSSL dll versione 1.0.1.

Mi sembra che l'utilizzo di OpenSSL con Delphi XE2 sia un po 'difficile da utilizzare. Un enorme ringraziamento al team di Indy per aver lavorato così duramente ... Ma qualcuno può aiutarli per favore? Questo è davvero un grande progetto e un ottimo prodotto, ma quando si rompe e quando si deve seguire uno standard in movimento (come l'implementazione di openSSL), forse un po 'più di documentazione, e test e eyeballs aiuterebbero. Sono pronto ad assistere se qualcuno può mostrarmi come posso dare una mano. I problemi con SSL non sono specifici all'indy, poiché noto che altri venditori di componenti e persone open source hanno versioni specifiche delle DLL OpenSSL che supportano o non supportano.

Un'altra cose tristi che ho imparato oggi: alcuni dei programmi di installazione di OpenSSL installare le loro DLL di default (senza preavviso) nella vostra finestre directory System32, causando non solo la vostra applicazione, ma altri, come TortoiseHg e TortoiseSVN, per rompere forse. Se non avevi un grosso problema con SSL prima di iniziare a giocare, potresti facilmente peggiorare la situazione se installi una serie di versioni del programma di installazione dallo OpenSSL website.