我正在开发一个 Web 服务，我需要通过 GET 方法向该服务发送用户名和密码。只要通过像 ssl 这样的安全通道，就可以在 uri 中发送此信息吗？换句话说，我可以有一个看起来像 /users/{username}/{cleartext_password} 的 uri 吗？
编辑：对不起，我想我不清楚。 Web 服务本质上只是一个用户名和散列密码的数据库。想象一个将用户名和密码保存在远程数据库中的桌面应用程序。最终用户在应用程序中输入他们的用户名和密码，然后应用程序访问 Web 服务以验证用户身份。
因此，应用程序需要将最终用户的用户名和明文密码发送到服务。该服务将获取用户名和密码，并检查用户名和密码的哈希值是否与数据库中的用户名和哈希密码匹配。应用程序本身必须先进行身份验证才能访问服务，但我只是想知道将最终用户的用户名和密码发送到服务以验证最终用户身份的最佳方式是什么。我不使用 POST 方法，因为我只是在进行身份验证，因此不会更改服务器的状态。对困惑感到抱歉。
【问题讨论】：
这样做。
发送一个“密钥”和一个“摘要”。
“key”相当于用户名。
“摘要”是密钥、URI 和“共享密钥”或密码的 SHA1（或 MD5）哈希。
当服务器收到此信息时，它会根据密钥、请求的 URI 和“共享密钥”或密码计算自己的摘要版本。未能匹配摘要是 401 错误响应。
【讨论】：
如果它通过安全通道，则以明文形式发送用户名和密码是没有问题的。我只是建议不要通过不安全的渠道将它们作为明文发送，也不要针对每个请求重复发送它们。
您可以做的是首先对 Web 服务进行身份验证（通过 ssl 以明文形式发送用户名和密码）并从服务器获取它可以识别的令牌。然后在每个后续请求中发送该令牌。
【讨论】：
一般来说这不是一个好主意...这些数据将出现在许多日志文件中，因此这些数据可能会被不应该看到的人看到。如果可以的话，至少你应该在发送之前对其进行散列或加密。
这里有一个更详细的相关讨论...Is an HTTPS query string secure?
【讨论】：
SSL 确实对 URI 进行了加密，但一定要看看一些替代方案。
HTTP Basic Auth 非常简单，浏览器、网络服务器等都很好地支持
它也不会以与 URI 相同的程度出现在日志文件中
注意：这只是一些纯文本 HTTP 标头，因此绝对不推荐用于非 SSL 应用程序。
【讨论】：