将用户名和密码发送到网络服务
我正在开发一个 Web 服务，我需要以 GET 方法向该服务发送用户名和密码。只要通过 ssl 等安全通道传输此信息，就可以在 uri 中发送此信息吗？换句话说，我可以有一个类似于 /users/{username}/{cleartext_password} 的 uri 吗？
编辑：抱歉，我想我不清楚。 Web 服务本质上只是一个用户名和散列密码的数据库。想象一个将用户名和密码保存在远程数据库中的桌面应用程序。最终用户在应用程序中输入用户名和密码，应用程序访问 Web 服务以对用户进行身份验证。
因此，应用程序需要将最终用户的用户名和明文密码发送到服务。该服务将获取用户名和密码，并检查用户名和密码的哈希值是否与数据库中的用户名和哈希值密码匹配。应用程序本身必须在访问服务之前进行身份验证，但我只是想知道将最终用户的用户名和密码发送到服务以对最终用户进行身份验证的最佳方式是什么。我不使用 POST 方法，因为我只是进行身份验证，因此不会更改服务器的状态。抱歉造成混乱。
I am developing a web service and I need to send a username and password to the service in a GET method. Is it OK to send this information in the uri as long as it's going over a secure channel like ssl? In other words, can I have a uri that looks like /users/{username}/{cleartext_password}?
Edit: Sorry, I think I was unclear. The web service is essentially just a database of usernames and hashed passwords. Imagine a desktop application that keeps usernames and passwords in a remote database. The end user types their username and password into the application and the application accesses the web service to authenticate the user.
So, the application will need to send an end user's username and plaintext password to the service. The service will take the username and password and check that the username and the hash of the password match the username and hashed password in the database. The application itself will have to authenticate before it can access the service, but I am just wondering what is the best way to send the end user's username and password to the service for authenticating the end user. I don't to use a POST method because I am simply authenticating and therefore not changing the state of the server. Sorry for the confusion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这样做。
发送“密钥”和“摘要”。
“密钥”相当于用户名。
“摘要”是密钥、URI 和“共享秘密”或密码的 SHA1（或 MD5）散列。
当服务器收到此信息时，它会根据密钥、请求的 URI 以及“共享秘密”或密码来计算自己的摘要版本。未能匹配摘要是 401 错误响应。
Do this.
Send a "key" and a "digest".
The "key" is equivalent to a username.
The "digest" is a SHA1 (or MD5) hash of the key, the URI and a "shared secret" or password.
When the server gets this, it computes it's own version of the digest, based on key, URI being requested and the "shared secret" or password. Failure to match digests is a 401 error response.
如果通过安全通道进行传输，则以明文形式发送用户名和密码是没有问题的。我只是建议不要通过不安全的通道以明文形式发送它们，并且不要为每个请求重复发送它们。
您可以做的是首先对 Web 服务进行身份验证（通过 ssl 以明文形式发送用户名和密码），然后从服务器获取它可以识别的令牌。然后随每个后续请求发送该令牌。
If it's going over a secure channel, there's no problem sending the username and password as cleartext. I'd just recommend against ever sending them as cleartext through an insecure channel and against sending them repeatedly for each request.
What you could do is first authenticate to the web service (send the username and password via ssl as cleartext) and get a token from the server that it will recognize. Then send that token with each subsequent request.
一般来说，这不是一个好主意...这些数据将出现在许多日志文件中，因此这些数据对于不应该看到它的人来说是可见的。如果可以的话，至少您应该在发送之前对其进行散列或加密。
以下是有关更多详细信息的相关讨论... HTTPS 查询字符串安全吗？
Generally speaking this is not a good idea... This data will be present in a number of log files, consequently the data could be visible to people who should not see it. At the very least you should hash or encrypt it before sending it if you can.
Here is a related discussion for a little more detail... Is an HTTPS query string secure?
SSL 确实会加密 URI，但一定要看看一些替代方案。
HTTP 基本身份验证很好且简单，并且受到浏览器、网络服务器等的良好支持。
它也不会像 URI 一样最终出现在日志文件中
注意：它只是一些纯文本 HTTP 标头，因此绝对不建议非-SSL 应用程序。
http://en.wikipedia.org/wiki/Basic_access_authentication
SSL does encrypt the URI, but definitely take a look at some alternatives.
HTTP Basic Auth is nice and simple, and well supported by browsers, webservers, etc
It also won't end up in log files to the same degree as URIs
NB: It's just some plain-text HTTP Headers, so definitiely NOT recommended for non-SSL apps.
http://en.wikipedia.org/wiki/Basic_access_authentication