Как я могу заставить Delphi XE2 общаться с API Календаря Google через SSL?

Время дляэтот вопрос еще раз, но на этот раз с Delphi XE2.

Я использую Indy версии 10.5.8.0, которая поставляется с XE2, и я пробовал четыре разные версии SSL-библиотек. Я попробовал последнюю версию 1.0.x и около 3 разных версий 0.9.8 (e, h, x, ....).

Ни одна из них не работает, когда вы общаетесь по https: // urls на calendar.google.com. Автор компонента Delphi Google Calendar на & quot;Sync-components.com& Quot; отправляет свой собственный двоичный файл Среды выполнения DLL openssl, в которых нет информации о версии, но, похоже, это очень маленькая, очень старая версия библиотек SSL старше 0.9.8. Автор компонента говорит, что известны только его частные неверсированные библиотеки DLL. Я не могу в это поверить. Конечно, по крайней мере одна версия openSSL dll работает достаточно хорошо с Delphi XE2 для подключения к Календарю Google.

Чтобы заставить свою собственную древнюю DLL загружаться в Indy 10 в Delphi XE2, он модифицирует метод Load IdSSLOpenHeaders.pas, например, в конце:

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

Конечно, компонент, который я оцениваю, не работает в XE2, но я подозреваю, что это нарушение либо (а) этого конкретного снимка Indy 10, поставляемого с XE2, либо (б) того факта, что World of SSL DLL - настоящий ад "сломан для вас, но работает для меня" разные версии.

Что мне нужно сделать, чтобы получить SSL-соединение с Календарем Google, используя Indy (или любую другую библиотеку компонентов delphi с поддержкой SSL) в Delphi XE2?

В качестве альтернативы, если у кого-то есть реализация API календаря Google, которая работает с чем-либо, кроме Indy, которое я мог бы использовать для тестирования, я был бы признателен за ссылки и указатели.

 Leonardo Herrera30 мая 2012 г., 17:17
Если у вас есть бюджет, посмотрите наSecureBlackBox, У них есть полнофункциональная пробная версия.
 Warren P30 мая 2012 г., 18:08
Они предоставляют общую поддержку https, но не представляют собой демонстрацию API Календаря Google, что заставляет меня задаться вопросом, есть ли какие-то странные вещи с параметрами аутентификации HTTPS в календаре Google или чем-то еще, потому что это то, о чем я спрашиваю: не только SSL, но сервер GOOGLE ssl.

Ответы на вопрос(1)

Решение Вопроса

который поставляется с XE2, в том, что объект idHTTP, кажется, не работает хорошо ни с одной из найденных мной библиотек OpenSSL, в том, что я не мог связаться с ними с любыми службами сервера Календаря Google.

По-видимому, реальная причина проблемы заключается в том, что Indy не обрабатывает перенаправления HTTP так прозрачно, как мы могли бы надеяться. Код, который манипулирует Indy (сторонним компонентом), делает некоторые действительно трудные для понимания вещи с Indy & quot; http redirect & quot; логика обработки, которая выглядит как набор обходных путей, которые не работают. Что еще более запутанно, так это то, что точные места в коде, где происходят перенаправления HTTP, варьируются от одного человека, тестирующего Google Календари, к другому, поэтому эти сбои перенаправления не всегда появляются в одних и тех же местах для каждого человека, тестирующего его.

Обратите внимание, что метод входа и метод, чтобы получить календари работали. Но методы и код, которые должны были читать события, похоже, не работают. Мне не удалось выяснить разницу между ними, но код, который я использую, является коммерческим, и я не могу опубликовать ни один из них. Я обновлю это сообщение, если когда-нибудь выясню фактическую техническую причину, по которой HTTP-запрос получения возвращал & quot; 0 байтов & quot; в своем ответе на URL, как это:

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

Эти нулевые результаты были действительно кодом ответа HTTP 302, который я не проверял и не ожидал. Он ожидал, что Indy автоматически обработает перенаправления.

Проблема может заключаться либо в том, что версия Indy10 очень специфична и работает только с той версией библиотеки openSSL, которую я не обнаружил в моем сегодняшнем поиске, либо в том, что версия Indy10, которая поставляется с XE2, не работает с ЛЮБОЙ версией OpenSSL dll, который я смог найти, по крайней мере, когда цель, с которой он общается, это серверы HTTPS-календарей google.

Код, который я запускаю, создает объект IdHTTP с TIdSSLIOHandlerSocketOpenSSL.

Это работает во всех версиях Delphi вплоть до XE, но не работает с заводской системой XE2 из-за версии Indy, поставляемой с XE2.

Единственное исправление, которое я нашел, - это установка новой ночной сборки Indy, я взял 4760, которая, кажется, работает нормально, в сочетании с OpenSSL dll версии 1.0.1.

Мне кажется, что использование OpenSSL с Delphi XE2 немного сложно из коробки. Огромное спасибо команде Indy за столь усердную работу ... Но кто-нибудь может помочь им? Это действительно отличный проект и отличный продукт, но когда он ломается и когда вам нужно следовать движущемуся стандарту (например, реализации openSSL), возможно, потребуется немного больше документации, а также тестирование и обзор. Я готов помочь, если кто-нибудь покажет мне, как я могу помочь. Проблемы с SSL не являются специфическими для индейцев, так как я заметил, что у других поставщиков компонентов и людей с открытым исходным кодом есть определенные версии библиотек OpenSSL, которые они поддерживают или не поддерживают.

Еще одна печальная вещь, которую я узнал сегодня: некоторые установщики из OpenSSL устанавливают свои библиотеки DLL по умолчанию (без предупреждения) в каталог Windows System32, что приводит к поломке не только вашего приложения, но и других, таких как TortoiseHG и TortoiseSVN. Если у вас не было больших проблем с SSL до того, как вы начали играть, вы могли бы легко усугубить ситуацию, установив несколько версий установщика изСайт OpenSSL.

 31 мая 2012 г., 16:22
@WarrenP - так что вкратце, что вы рекомендуете? Лично я никогда не использую версию Indy для доставки, а вместо этого использую версию SVN. Конечно, это не бесплатный обед, но я обнаружил, что предпочитаю перекомпилировать все (Indy и любые сторонние компоненты, которые его используют) вместо того, чтобы устранять недостатки поставляемых версий (которые по некоторым причинам всегда имеют некоторые проблемы)
 Warren P31 мая 2012 г., 03:57
Хороший вопрос, Миша. Я планирую сделать это так во время разработки и развертывания.
 31 мая 2012 г., 01:26
У меня всегда есть необходимые библиотеки в каталоге приложения, чтобы избежать проблем с установкой. Если версия стороннего API специфична для вашего проекта, то ВСЕГДА файлы будут доступны локально.
 Warren P01 июн. 2012 г., 02:28
Ну, мой поставщик компонентов говорит, что у него все отлично работает с XE2, использующим поставляемую версию Indy, и, тем не менее, даже его собственная демонстрация не работает, когда я компилирую ее с версией Indy из XE2. Последняя и самая лучшая версия также не всегда стабильна. Таким образом, вы просто должны заплатить деньги и рискнуть. Это не идеально, и именно поэтому я заявил в последнем абзаце, что люди должны проводить еще несколько тестов сообщества на Indy + HTTPS, и, возможно, проект Indy мог бы выпустить некоторые стабильные версии и сохранить эти архивы.

Ваш ответ на вопрос