Google 通讯录 API - 无重定向
我目前正在开发 Contact Importer Web 应用程序（使用 PHP），因此我将能够从 Gmail、Yahoo 等用户的帐户中获取电子邮件地址，并将它们用于我自己的邪恶目的。开玩笑，我的网络应用程序非常友好。
我想我会从谷歌开始。我发现他们有一个很棒的小 API，称为 Google Contacts API，它可以让像我这样的程序员访问用户的联系人。
经过几个小时的努力并把糟糕的代码放在一起后，我遇到了一些障碍。我的主要问题是：
有什么方法可以让用户在我的网站上提供 Gmail 用户名和密码，并让我的代码检索联系人而不会重定向到 Google登录页面？这有点破坏了我的网络应用程序的整个流程。
我研究了 AuthSub，并让它工作，但当然，问题是你必须重定向用户才能获取访问令牌。看起来 OAuth 也会有同样的问题。
我的一线希望是 ClientLogin 身份验证方法。同样，有一个问题，有时 Google 会向您抛出验证码而不是身份验证令牌。再次，用户流程被破坏。
我注意到 Twitter 上我们的好朋友们都运行得很好。有谁知道他们是怎么做到的？
谢谢！
I am currently working on Contact Importer web app (in PHP) so I will be able to grab email address from a user's account on Gmail, Yahoo, etc and use them for my own evil purposes. Just kidding, my web app is very friendly.
I thought I would start with Google. I found they have a fantastic little API called Google Contacts API which lets a programmer, like myself, to access a user's contacts.
After a couple of hours of struggling and throwing shitty code together, I ran into a few road-blocks. My main question is this:
Is there any way that I can have a user provide their username and password for Gmail on my website and have my code retrieve the contacts without that nasty redirection to a Google login page? It's kind of ruins the whole flow of my web app.
I've looked into AuthSub, and gotten that to work, but of course the catch is that you have to redirect the user to obtain the access token. It looks like OAuth will have this same catch.
The one ray of hope I have is the ClientLogin method of authentication. Again, there is a catch, sometimes Google throws you a CAPTCHA instead of the auth token. Again, the user flow is ruined.
I've noticed that our good ol' friends over at Twitter have it working just fine. Does anyone know how they do it?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您已经确定了一个功能，而不是一个错误。 OAuth 的全部目的是防止用户在像您这样的第三方网站中输入密码：这样他们就可以学会仅在查看 Google 登录页面时输入 Google 密码，而不必相信您已成功不要存储他们的密码并用它来阅读他们的所有电子邮件。
它确实会在您的 Web 应用程序流程中提供一个小中断，但 OAuth 通常会提供回调，因此它不会真正造成大的中断。作为交换，您的用户可以感到更安全，并且您可以避免必须存储（然后处置）用户密码的任何问题。
简而言之，我认为你无法解决这个问题。确实，Twitter 目前确实允许这样做（“基本身份验证”，直接发送用户名和密码），但该功能计划为 今年夏天已弃用。
I think you've identified a feature, not a bug. The whole point of OAuth is to prevent users from typing their passwords into third-party sites like yours: this way they can learn to only type their Google password when they're looking at a Google login page and not have to trust that you won't store their password and use it to read all of their email.
It does provide a small interruption in the flow of your web app, but OAuth generally provides a callback so that it shouldn't really be a large disruption. In exchange, your users can feel safer and you can avoid any issues of having to store (and then dispose of) user passwords.
In short, I don't think you'll be able to get around this. It's true that Twitter does currently allow it ("Basic Auth", where the username and password are sent directly), but that feature is planned to be deprecated by this summer.