C# 中使用 oAuth 的 AdWords SOAP 请求
我正在尝试升级可能的程序以支持 Google 在 AdWords 中使用的新 oAuth。
我有我的在线部分，它工作正常，并获取访问令牌（令牌、秘密和消费者密钥）。
我的问题是当我稍后尝试使用这些凭据发出肥皂请求时。
A. 我需要从OnLine部分保存哪些信息？到目前为止，我只保存了 accessToken 和 accessTokenSecret。
B. 如何使用 accessToken、accessTokenSecret 以及我保存的其他内容来发出 SOAP 请求？
有关我的流程的一些信息：
- 不使用 Google 的客户端库（开销太大，到目前为止我不需要它们）
- 在我正在使用的服务上使用使用 VS2005 WSDL 的自动生成的代码。
- C#
I'm trying to upgrade may program to support the new oAuth that Google uses in the AdWords.
I've my on-line part, which work fine, and get the access tokens (token, secret and consumer key).
My problem is when I try to make a soap request later with those credentials.
A. Which information do I need to save from the OnLine part? so far I save only the accessToken and the accessTokenSecret.
B. How do I use the accessToken, accessTokenSecret and what ever else I've saved in order to make a SOAP requests?
Some info on my process:
- Not using the Client Library from Google (too much over head, and so far I didn't needed them)
- Using the auto-generated code using VS2005 WSDL on the services I'm using.
- C#
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题是你想做的事情有点复杂。与 AdWords API 实现相比，它与 oAuth 流程本身的关系更大。我认为在这种情况下使用客户端库会非常有益。
您实际上需要使用您的令牌和消费者密钥来签署请求。这可以使用 RSA-SHA1 或 RSA-HMAC 来完成；首先，您使用私钥文件对其进行签名，并将公钥上传到 Google；对于 RSA-HMAC，您只需使用令牌和消费者机密，而不是公钥/私钥。
您可以在此处了解有关执行此操作的更多信息，但我会建议仅使用 Google 的实现，除非您对 oAuth 的内部结构感兴趣。前一段时间我自己尝试了一下，发现相当复杂。
The problem is that what you're trying to do is a bit involved. It's got more to do with the oAuth process itself than the AdWords API implementation. I think that this is a case where it would be very beneficial to use the client library.
You actually need to use your token and consumer key to sign the request. This can either be done using RSA-SHA1 or RSA-HMAC; in the first instance you sign it with a private key file and upload the public key to Google; for RSA-HMAC you just use the token and consumer secrets instead of the public/private key.
You can find out more about doing this here, but I would recommend just using Google's implementation unless you're interested in the internals of oAuth. I tried it myself a while ago and found it quite complicated.