14

もう一度この質問の時間ですが、今回はDelphiXE2を使用します。

XE2に同梱されているIndyバージョン10.5.8.0を使用しており、SSLdllの4つの異なるバージョンを試しました。最新の1.0.xと、約3つの異なる0.9.8バージョン（e、h、x、....）を試しました。

calendar.google.comのhttps：// urlsと通信する場合、これらはいずれも機能しません。「 Sync-components.com 」のDelphiGoogleカレンダーコンポーネントの作成者は、バージョン情報が含まれていない独自のバイナリopenssl DLLランタイムを出荷していますが、0.9より古いSSLライブラリの非常に小さい非常に古いバージョンのようです。 8.8。コンポーネントの作成者は、バージョン管理されていないプライベートDLLのみが機能することがわかっていると述べています。信じられない。確かに、openSSL dllの少なくとも1つのバージョンは、Googleカレンダーに接続するためにDelphiXE2で十分に機能します。

カスタムの古代DLLをDelphiXE2のIndy10にロードするために、彼は最後にIdSSLOpenHeaders.pasメソッドLoadを次のように変更します。

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

もちろん、私が評価しているコンポーネントはXE2では機能しませんが、（a）XE2に同梱されているIndy 10のこの特定のスナップショット、または（b）SSLDLLの世界が「あなたのために壊れたが、私のために働く」さまざまなバージョンの真の地獄。

Delphi XE2でIndy（またはSSLをサポートする他のdelphiコンポーネントライブラリ）を使用して、GoogleカレンダーへのSSL接続を取得するにはどうすればよいですか？

または、テストに使用できるIndy以外のもので動作するGoogleカレンダーAPI実装を持っている人がいる場合は、リンクとポインターをいただければ幸いです。

4

1 に答える 1

6

XE2に同梱されているIndy10のスナップショットには、idHTTPオブジェクトが、Googleカレンダーサーバーサービスと通信できなかったという点で、私が見つけたOpenSSLdllのいずれでもうまく機能していないように見えるという点で問題があります。

問題の実際の根本的な性質は、IndyがHTTPリダイレクトを私たちが期待していたほど透過的に処理しないことであるように思われます。Indy（サードパーティコンポーネント）を操作しているコードは、一連の回避策のように見えるIndyの「httpリダイレクト」処理ロジックを使用して、機能しないことを理解するのが非常に困難です。さらに紛らわしいのは、HTTPリダイレクトが発生するコード内の正確な場所は、Googleカレンダーをテストする人によって異なるため、これらのリダイレクトの不具合は、テストする人ごとに同じ場所に表示されるとは限らないことです。

ログイン方法、およびカレンダーを機能させる方法に注意してください。しかし、イベントを読み取るためのメソッドとコードは機能していないようです。両者の違いがわかりませんでしたが、使用しているコードは商用であり、投稿することはできません。HTTP getリクエストが次のようなURLの応答で「0バイト」を返していたという実際の技術的な理由を理解した場合は、このメッセージを更新します。

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

これらのゼロバイトの結果は、実際にはHTTP 302リダイレクト応答コードであり、私が使用していたコードはチェックも期待もしていませんでした。Indyがリダイレクトを自動的に処理することを期待していました。

問題は、Indy10バージョンが非常に特殊であり、今日の検索で見つけられなかったバージョンのopenSSL dllでのみ機能するか、XE2に付属するIndy10バージョンが私が見つけたOpenSSLdllは、少なくともそれが話しているターゲットがgoogleのHTTPSカレンダーサーバーである場合はそうではありません。

私が実行しているコードは、TIdSSLIOHandlerSocketOpenSSLを使用してIdHTTPオブジェクトを作成します。

これは、XEまでのすべてのバージョンのDelphiで機能しますが、XE2に同梱されているIndyバージョンのため、工場出荷時のXE2システムでは機能しません。

私が見つけた唯一の修正は、Indyの新しいナイトリービルドをインストールすることです。OpenSSLdllバージョン1.0.1と組み合わせると、正常に動作するように見える4760を取得しました。

Delphi XE2でOpenSSLを使用するのは、箱から出してすぐに少し難しいように思えます。インディチームに一生懸命働いてくれて本当にありがとう…。でも誰か助けてくれませんか？これは本当に素晴らしいプロジェクトであり、素晴らしい製品ですが、それが壊れたときや、移動する標準（openSSL実装など）に従わなければならないときは、おそらくもう少しドキュメント、テスト、そして目玉が役立つでしょう。誰かが私がどのように助けることができるかを私に示すことができれば、私は助ける準備ができています。他のコンポーネントベンダーやオープンソースの人々が、サポートしている、またはサポートしていないOpenSSL dllの特定のバージョンを持っていることに気付いたので、SSLの問題は個別のものではありません。

今日私が学んだもう1つの悲しいこと：OpenSSLのインストーラーの一部はデフォルトで（警告なしに）WindowsのSystem32ディレクトリにDLLをインストールし、アプリだけでなく、TortoiseHGやTortoiseSVNなどの他のインストーラーも壊れてしまう可能性があります。遊び始める前にSSLに大きな問題がなかった場合は、OpenSSL Webサイトから多数のインストーラーバージョンをインストールすると、簡単に悪化する可能性があります。

于 2012-05-30T19:51:26.703 に答える