C2DM with ClientLogin with server

Question

私はRubyで書かれたモバイルアプリケーション用のサーバー側のソリューションに取り組んでいます。私たちの要件の一部は、Google's C2DMサービスが理想的と思われるアップデートされたペイロードを受信するために、分散したクライアントに電話の家に通知することです。

私はすでに必要なものをすべて試作してテストし、そのソリューションがローカルマシンから動作することを確認しました。 （C2DM library for Rubyを使用して、リンクは、証明書がGoogleのapiサブドメインをカバーしていないSSL証明書の問題を解決するために進行中の私自身のフォークにある。）Google's ClientLogin API内の1つの主要なしゃっくりを除い：

我々の開発に展開しますアプリケーションサーバー私はメッセージを送信できませんでした。結果をさらに深く掘り下げてみると、開発中にローカルで作成した有効なauth_tokenを使用していたにもかかわらず、CAPTCHAREQUIREDとcaptchaトークンにcaptchaイメージのURLを加えた返信をGoogleから受け取っていたことがわかりました。だから私は自分のブラウザを使ってCAPTCHAを要求し、それを解決し、私たちの開発サーバからClientLoginへの返信を投稿するためにカールを使用した後、メッセージを送信するためにはauth_tokenが必要でした。

これは、私が運用環境に展開するときに同様の認証の問題が発生すると心配していました。チームメイトと私はもう少し研究を重ねて、auth_tokenが期限切れになるという正確な仕様は誰も知っていませんが、「少なくとも2週間」有効であると主張する少なくとも1人のGoogleエンジニアがいます。次に、ClientLoginレスポンスがCAPTCHAREQUIREDと表示されたときに、ops/devopsの人にページ/電子メールを送信してCAPTCHAを解決し、サーバーアプリケーションのページ/ツールを使用して回答を送信して新しいauth_tokenを取得することを提案します。 （これが私がしなければならないことなら、Amazonのメカニカル・タークはその日を節約するだろうと思う）

少なくとも初期インストール中にCAPTCHAを解決する。私たちは生産環境を管理しています。これは大した問題ではなく、まさにCAPTCHAREQUIREDチャレンジレスポンスを引き起こす原因がわからないため、わずかな不便です。 （私たちは、以前は知られていなかったアカウントのIPアドレスを理論化しています）

私は何かひどくやっていると思っています。

Answer 1

認証トークンライフタイムの問題は、依然として大気中です。 C2DMは正式にはベータ版なので、Googleの人々は確固たる姿勢に挑戦したくありません。理解できますが、イライラします。

私の経験上、C2DMの目的で専用のGoogleアカウントを使用した場合、CAPTCHAチャレンジは決して起こらないと言いました。