我正在为用 Ruby 编写的移动应用程序开发服务器端解决方案。我们的部分要求是通知我们的分布式客户端打电话回家以接收更新的有效负载 Google's C2DM服务似乎很理想。
我已经制作了原型(prototype)并测试了我们需要的一切，并验证了该解决方案可以在我的本地机器上运行。 (使用 C2DM library for Ruby，链接指向我自己的分支，用于解决 SSL 证书问题，其中证书不涵盖 Google 的 api 子域。)除了 Google's ClientLogin 中的一个主要问题。应用程序接口(interface):
当部署到我们的开发应用程序服务器时，我无法传输消息。深入研究结果，我发现我们收到了 Google 的回复，内容为 CAPTCHAREQUIRED和验证码 token 加上验证码图像的 URL，尽管我使用的是有效的 auth_token我在开发过程中在本地创建。所以我使用我自己的浏览器请求验证码并解决它，然后使用 curl 将我们开发服务器的回复发布到 ClientLogin 之后我能够获得 auth_token传输消息所必需的。
这让我担心在部署到生产环境时会发生类似的身份验证挑战。因此，我和一位队友进行了更多研究，发现虽然没有人知道关于何时 auth_token 的确切规范。可能会过期 至少有一位所谓的谷歌工程师声称他们的有效期为“至少两周”。那么建议的解决方案是，当 ClientLogin 响应指示 CAPTCHAREQUIRED 时您寻呼/发送电子邮件给 ops/devops 人员来解决 CAPTCHA，并使用服务器应用程序中的页面/工具提交答案以获得新的 auth_token . (如果这是我必须做的，我想亚马逊的 Mechanical Turk 可以挽救这一天？)
当然，这些信息确实有可能已经过时，但这并不能改变我至少在初始安装期间仍然需要解决验证码的事实。我们控制生产环境，所以这不是什么大问题，只是带来一些不便，因为我们不知道到底是什么导致了 CAPTCHAREQUIRED。挑战响应。 (我们推测它是该帐户以前未知的 IP 地址。)
我忍不住想我在这里做的事情非常非常错误。
最佳答案
授权 token 生命周期的问题仍然悬而未决。 C2DM 正式仍处于测试阶段，因此 Google 人员不想 promise 一个可靠的数字。可以理解，但令人沮丧。
也就是说，根据我的经验，如果您将专用的 Google 帐户用于 C2DM 目的，则永远不会出现 CAPTCHA 挑战。
关于android - 在服务器上使用 ClientLogin 的 C2DM，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8596408/