delphi - not - download openssl indy

¿Cómo puedo hacer que Delphi XE2 hable con las API de Google Calendar a través de SSL?

Question

Es hora de que vuelva a hacerse esta pregunta , pero esta vez con Delphi XE2.

Estoy usando la versión de Indy 10.5.8.0 que se incluye con XE2, y he probado cuatro versiones diferentes de los dlls de SSL. He intentado 1.0.x más reciente y aproximadamente 3 versiones diferentes de 0.9.8 (e, h, x, ....).

Ninguno de ellos funciona cuando se comunica con https: // urls en calendar.google.com. El autor del componente Google Calendar de Delphi en " Sync-components.com " envía sus propios tiempos de ejecución DLL binarios de openssl que no tienen información de versión, pero parece ser una versión muy pequeña y antigua de las librerías SSL anteriores a la 0.9. 8. El autor del componente dice que solo se sabe que sus archivos DLL privados no versionados funcionan. No puedo creer eso. Seguramente al menos una versión de los DLL de openSSL funciona lo suficientemente bien con Delphi XE2 para conectarse a Google Calendar.

Para que su antigua DLL personalizada se cargue en Indy 10 en Delphi XE2, modifica el método IdSSLOpenHeaders.pas Load, así, al final:

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

Por supuesto, el componente que estoy evaluando no funciona en XE2, pero sospecho que es la ruptura de (a) esta instantánea particular de Indy 10 que se incluye con XE2, o (b) el hecho de que el mundo de las DLL SSL es un verdadero infierno de versiones "roto para ti pero que funciona para mí".

¿Qué tengo que hacer para obtener una conexión SSL a Google Calendar, usando Indy (o cualquier otra biblioteca de componentes Delphi con soporte SSL) en Delphi XE2?

Alternativamente, si alguien tiene una implementación de la API de calendario de Google que funciona con cualquier otra cosa que no sea Indy que pueda usar para las pruebas, agradecería enlaces y punteros.

Answer 1

Hay algo mal con la instantánea de Indy10 que se incluye con XE2, ya que el objeto idHTTP parece no funcionar bien con ninguno de los dlls OpenSSL que encontré, ya que no pude comunicarme con ninguno de los servicios de servidor de Google Calendar.

La verdadera naturaleza subyacente del problema parece ser que Indy no maneja los redireccionamientos HTTP tan transparentemente como podríamos haber esperado. El código que manipula Indy (componente de terceros) hace cosas realmente difíciles de entender con la lógica de manejo de "http redirect" de Indy que parece ser un conjunto de soluciones alternativas que no funcionan. Lo que es más confuso es que los lugares exactos en el código donde se producen los redireccionamientos HTTP varían desde una persona que prueba los calendarios de Google a otra, por lo que estas fallas técnicas de redirección no siempre aparecen en los mismos lugares para cada persona que las prueba.

Tenga en cuenta que el método de inicio de sesión y el método para obtener los calendarios funcionan. Pero los métodos y el código que debían leer los eventos parecen no funcionar. No pude averiguar la diferencia entre los dos, pero el código que estoy usando es comercial y no puedo publicar nada de eso. Actualizaré este mensaje si alguna vez averiguo el motivo técnico real por el cual la solicitud de obtención de HTTP devolvía "0 bytes" en su respuesta para direcciones URL como esta:

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

Esos resultados de cero bytes fueron realmente el código de respuesta de redireccionamiento HTTP 302, que el código que estaba usando no se verificó o esperó. Esperaba que Indy manejara automáticamente los redireccionamientos.

El problema podría ser que la versión de Indy10 es muy específica y solo funciona con una versión de los DLL de openSSL que no encontré en mi búsqueda de hoy, o que la versión de Indy10 que se incluye con XE2 no funciona con CUALQUIER versión de los dlls de OpenSSL que pude encontrar, al menos no cuando el objetivo con el que está hablando son los servidores de calendario HTTPS de Google.

El código que estoy ejecutando crea un objeto IdHTTP con un TIdSSLIOHandlerSocketOpenSSL.

Esto funciona en todas las versiones de Delphi hasta e incluyendo XE, pero se rompe con un sistema XE2 de fábrica, debido a la entrega de la versión de Indy con XE2.

La única solución que he encontrado es instalar una nueva versión nocturna de Indy, agarré 4760, que parece funcionar bien, cuando se combina con OpenSSL dll versión 1.0.1.

Me parece que usar OpenSSL con Delphi XE2 es un poco difícil de usar. Muchísimas gracias al equipo de Indy por trabajar tan duro ... ¿Pero alguien puede por favor ayudarlos? Este es realmente un gran proyecto y un gran producto, pero cuando se rompe, y cuando tienes que seguir un estándar en movimiento (como la implementación de openSSL), tal vez un poco más de documentación y pruebas te ayuden. Estoy listo para ayudar si alguien puede mostrarme cómo puedo ayudar. Los problemas con SSL no son específicos de un indy, ya que noto que otros proveedores de componentes y gente de código abierto tienen versiones específicas de los dlls de OpenSSL que admiten o no son compatibles.

Otra triste cosa que aprendí hoy: algunos instaladores de OpenSSL instalan sus DLL por defecto (sin aviso) en su directorio Windows System32, causando que no solo su aplicación, sino que otras, como TortoiseHG y TortoiseSVN, se rompan. Si no tuvo un gran problema con SSL antes de empezar a jugar, podría empeorarlo fácilmente si instala una gran cantidad de versiones de instalación desde el sitio web de OpenSSL .