2010-05-20 142 views
6

我正在开发一个Web服务,我需要在GET方法中向服务发送用户名和密码。只要它通过像ssl这样的安全通道就可以在uri中发送这些信息吗?换句话说,我可以拥有一个看起来像/ users/{username}/{cleartext_password}的uri吗?发送用户名和密码到Web服务

编辑:对不起,我想我不清楚。 Web服务本质上只是用户名和散列密码的数据库。想象一下,将用户名和密码保存在远程数据库中的桌面应用程序。最终用户将他们的用户名和密码输入到应用程序中,然后应用程序访问Web服务以对用户进行身份验证。

因此,应用程序需要向服务发送最终用户的用户名和明文密码。该服务将获取用户名和密码,并检查用户名和密码的散列与数据库中的用户名和散列密码相匹配。应用程序本身在访问服务之前必须进行身份验证,但我只是想知道将最终用户的用户名和密码发送到服务以验证最终用户的最佳方式。我不使用POST方法,因为我只是进行身份验证,因此不会更改服务器的状态。对困惑感到抱歉。

回答

0

一般来说,这不是一个好主意......这些数据将出现在多个日志文件中,因此数据可能会被不应该看到的人看到。如果可以的话,至少应该在发送之前对其进行散列或加密。

这里是一个小更详细的相关讨论... Is an HTTPS query string secure?

+0

或者你可以看看做双向SSL认证。用户需要使用与服务器相同的证书,但服务器可以安全地对用户进行身份验证。 – mpez0 2010-05-20 18:57:15

0

如果它要通过安全通道,有作为发送明文用户名和密码没有问题。我只是建议不要将它们作为明文通过不安全的通道发送,并针对每个请求反复发送它们。

你可以做的是首先对Web服务进行身份验证(通过SSL发送用户名和密码作为明文),并从服务器获取它将识别的令牌。然后发送该标记与每个后续请求。

+0

例如,Google允许您通过SSL发送您的用户名和密码以检索其API的SID ...然后您将该SID发送到每个后续GET请求的cookie中。它工作得很好。 – EAMann 2010-05-20 18:48:28

7

做到这一点。

发送“密钥”和“摘要”。

“键”相当于一个用户名。

“摘要”是密钥,URI和“共享密钥”或密码的SHA1(或MD5)散列。

当服务器得到它时,它根据请求的密钥URI和“共享密钥”或密码计算出它自己的摘要版本。未能匹配摘要是401错误响应。

+0

这实际上是一个非常优雅的解决方案... – EAMann 2010-05-20 18:56:11

0

SSL确实会对URI进行加密,但绝对要看看一些替代方法。

HTTP基本验证是好的,简单,和由浏览器,Web服务器以及支持等

它还在日志文件中会不会落得相同的程度的URI

注意:这只是一些纯文本的HTTP头,所以非常不推荐用于非SSL应用。

http://en.wikipedia.org/wiki/Basic_access_authentication

相关问题