0

我正在尝试使用授权的应用程序编写脚本来更新各种数据集上的元数据。使用 OAuth 似乎是错误的方法(它不是一个面向 Web 的应用程序供其他用户自己使用),并且传递我自己的用户名和密码似乎......很恶心。

SODA API 身份验证文档非常混乱:

所有经过 HTTP 基本身份验证的请求都必须通过安全 (https) 连接执行,并且应该包含一个应用程序令牌,该令牌是在您注册应用程序时获得的。但是,身份验证 [原文如此,应该是“应用程序”?] 对请求进行身份验证时,令牌并不是严格要求的。通过不安全连接发出的经过身份验证的请求将被拒绝。

这是一个使用 HTTP 基本身份验证的示例 HTTP 会话:

POST /resource/4tka-6guv.json HTTP/1.1
Host: soda.demo.socrata.com
Accept: */*
Authorization: Basic [REDACTED]
Content-Length: 253
Content-Type: application/json
X-App-Token: [REDACTED]

所以:

  1. 你甚至可以使用应用令牌 + 秘密令牌来通过 HTTP 基础进行身份验证吗?
  2. 两个“[REDACTED]”中的哪一个是应用令牌,哪个是秘密令牌?

我的猜测(基于一些测试)是答案是:

  1. 第一个“[REDACTED]”是base64版本的username+password,第二个是application token,和认证无关。
4

1 回答 1

1

应用程序令牌和秘密令牌实际上并不与任何类型的预烘焙用户身份验证相关联。它们与您的应用程序相关联,然后在 OAuth 中使用,以确保您的应用程序在用户通过 OAuth 工作流程时与其声称的一样。用户进行身份验证后,应用程序可以检索用于实际验证其请求的身份验证令牌。

您真正需要的是一种检索“不记名令牌”的方法,某些 API 提供者允许您生成该令牌。这将允许您基本上“预 OAuth”并获得身份验证令牌,而无需完成完整的工作流程。不幸的是,我们还不是其中之一,因此您需要使用普通的旧 HTTP Basic 以及您的用户名和密码进行身份验证。

如果您想要一种稍微不那么棘手的方法来做到这一点,我建议您注册一个“机器人”帐户,您只授予对必要数据集的必要权限。那么至少您不会将常规用户凭据烘焙到您的配置中。但请记住,即使我们有不记名令牌,您也会将它们放入您的配置中的某个地方。

要回答您更具体的问题:

  1. 不,因为那样的话其中一个必须是不记名令牌,而事实并非如此。
  2. Authorization头是 Base64 编码的username:password,而X-App-Token是您的应用程序令牌。在这种情况下,后者只是一个额外的标头,可以将该请求标识为来自您的应用程序。

感谢您对文档的反馈 - 我会清理它们并尝试更直接,我一定会修复那个错字。

于 2016-11-08T01:09:13.780 回答