从 Scribe 的请求标头中删除 oauth_token

发布于 2024-12-20 22:42:31 字数 1500 浏览 2 评论 0原文

我们正在尝试连接另一家公司的自定义 API,该 API 使用两条腿 OAuth 来验证请求并向我们发送响应。

目前,我们的代码正在发送请求,但另一端未对其进行身份验证,因此发送未经授权的响应。

到目前为止我们研究的步骤:

  • 使用 Python 中的 OAuth 实现,使用相同的凭据连接到远程站点。
  • 要求另一家公司将我们的 OAuth 请求与另一家成功的公司进行比较,看看我们的 OAuth 请求是否缺少任何内容。

在上面的第二点之后,我们的请求和另一个工作请求之间的唯一区别是 oauth_token 参数存在于我们的请求中,而不是其他请求中。此外,他说他们的大多数请求中都有一个oauth_body_hash_value,但我们的请求中没有 - 尽管他们确实收到了没有它的工作请求。

有没有办法删除 Scribe 中的 oauth_token 参数?或者,是否始终需要oauth_body_hash_value?没有请求可以工作吗?

我已经包含了下面的代码,我对 OAuth 完全陌生,所以请随时告诉我是否还有其他问题。

请注意,TestAPI.class 扩展了 DefaultAPI10a,并且只为所有三个必需方法返回“”。

public class TestImporter {

  private static final String REQ_URL   = "http://test.com/";

  private static final String KEY         = "KEY";
  private static final String SECRET      = "SECRET";

  // test variables
  private static final String VAR1        = "Test123";

  public static void main(String[] args) {

    OAuthService service = new ServiceBuilder()
                               .provider(TestAPI.class)
                               .apiKey(KEY)
                               .apiSecret(SECRET)
                               .build();
    Token token = new Token("", "");
    OAuthRequest request = new OAuthRequest(Verb.GET, REQ_URL + VAR1 + "/");
    service.signRequest(token, request);
    Response response = request.send();
    System.out.println(response.getBody());

  }

}

We're trying to connect with another company's custom API which uses two-legged OAuth to authenticate a request and send us a response.

At the moment the code we have is sending a request but it's not being authenticated at the other end and so sending a UNAUTHORISED response.

The steps we have investigated so far:

  • Connected to the remote site using an OAuth implementation in python using the same credentials.
  • Asked the other company to compare our OAuth request with another that succeeds to see if there is a anything missing in ours.

After the second point above, the only difference between our request and another working request is that the oauth_token parameter is present in our request and not in others. Furthermore, he said they have an oauth_body_hash_value in most of their requests but that's not present in ours - although they do get working requests without it.

Is there a way to remove the oauth_token parameter in Scribe? Alternatively, is the oauth_body_hash_value always needed? Can a request work without?

I've included the code below, I am completely new to OAuth so please feel free to tell me if there's something else that's wrong.

Note that the TestAPI.class extends DefaultAPI10a and just returns "" for all three required methods.

public class TestImporter {

  private static final String REQ_URL   = "http://test.com/";

  private static final String KEY         = "KEY";
  private static final String SECRET      = "SECRET";

  // test variables
  private static final String VAR1        = "Test123";

  public static void main(String[] args) {

    OAuthService service = new ServiceBuilder()
                               .provider(TestAPI.class)
                               .apiKey(KEY)
                               .apiSecret(SECRET)
                               .build();
    Token token = new Token("", "");
    OAuthRequest request = new OAuthRequest(Verb.GET, REQ_URL + VAR1 + "/");
    service.signRequest(token, request);
    Response response = request.send();
    System.out.println(response.getBody());

  }

}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

梦萦几度 2024-12-27 22:42:31

关于您自己的答案似乎您想要做的是将签名放在查询字符串中而不是使用授权 标题。

尽管有效,但不建议这样做。无论如何,如果您确实需要这样做,有一种方法可以创建 OAuthService 来在查询字符串中“签名”:

ServiceBuilder()
  .provider(TestAPI.class)
  .apiKey(KEY)
  .apiSecret(SECRET)
  .signatureType(SignatureType.QueryString)
  .build();

Regarding your own answer seems that what you want to do is put the signature in the querystring and not use the Authorization header.

This, though valid is not recommended. Anyway if you really need to do it, there's a way of creating the OAuthService to "sign" in the querystring:

ServiceBuilder()
  .provider(TestAPI.class)
  .apiKey(KEY)
  .apiSecret(SECRET)
  .signatureType(SignatureType.QueryString)
  .build();
说不完的你爱 2024-12-27 22:42:31

假设它们的实现没有被破坏,那么包含“额外”的 OAuth 标头应该没有关系。话虽如此,oauth_token 标头不是可选(我假设您正在使用 OAuth 1.0 进行通信)。此标头应包含用户的访问令牌。在您的示例中,您将此标记显示为空白,这很奇怪!

现在假设由于某种原因向该第三方系统发送空白“用户名”是有效的,您将需要确保您的 OAuth 签名在双方(您的和其他公司)都匹配。使用协议嗅探器捕获 oauth_signature 标头的值,然后要求您的第三方验证他们是否生成相同的签名。如果没有,那么您可能遇到签名哈希问题。

Assuming their implementation is not broken, it should not matter that you have 'extra' OAuth headers included. Having said that, the oauth_token header is not optional (I assume you are communicating using OAuth 1.0). This header should contain the access token for the User. In your example you show this token as being blank, which is quite odd!

Now assuming for some reason that it is valid to send blank 'usernames' to this third party system, you will want to make sure that your OAuth signature is matching on both sides (yours and the other companies). Use a protocol sniffer to capture the value of the oauth_signature header, then ask your third party to verify that they generate a signature which is the same. If not then you probably have a signature hashing problem.

悟红尘 2024-12-27 22:42:31

事实证明,当我们认为自己正在发送完整的 HTTP GET 请求时,事实并非如此。

该库将所有信息添加到标头(我们从中获取信息的位置),但没有将任何 oauth 信息添加到请求 URL。我只能假设这与我们使用两条腿授权有关(因此是空令牌)。

通过将 oAuthParameters 的映射复制到 queryStringParameters 中,就可以正确形成 Url。

It turns out that when we thought we were sending a fully formed HTTP GET request, we weren't.

The library was adding all of the information to the header (where we were getting our information from), but not adding any oauth information to the request Url. I can only assume it's to do with us using two-legged authorisation (hence the empty Token).

By copying the map of oAuthParameters into queryStringParameters, it then allowed the Url to be formed correctly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文