情景：
我有一个带有webservices的ASP.Net / Silverlight网站，用于支持带有数据的Silverlight应用程序。该网站使用表单身份验证，因此Web服务也可以验证请求。
现在我想从这个系统中将一些数据提取到Android应用程序中。我可以实现运行表单登录的代码，并存储身份验证cookie，但在webservice url中发送用户名和密码并验证每个调用实际上要简单得多。我并没有真正看到这个问题，因为通信是SSL加密的，但是我愿意接受其他信息;）
你怎么看？不好主意/不是那么糟糕吗？结论：
在查看答案后，url请求字符串中针对name / pass的唯一真正有效的参数是它存储在服务器日志文件中。当然，这是我的服务器，如果该服务器被黑客入侵，它存储的数据也将被黑客入侵，但我仍然不喜欢日志中显示的密码。 （这就是为什么它们被存储盐渍和加密）
解决方案：
我会在请求中发布用户名和密码。最少的额外工作，更安全。
答案 0 :(得分：7)
请参阅Are querystring parameters secure in HTTPS (HTTP + SSL)?
所有内容都将被加密，但URL和查询字符串（以及密码）将显示在服务器日志文件中。
答案 1 :(得分：3)
错误想法：您帖子的内容已加密，虽然网址参数也可能已加密，但第三方跟踪器，服务器日志或其他某些监控软件仍可看到它们可以直接嗅你的流量。以这种方式打开潜在的安全漏洞并不是一个好主意。
答案 2 :(得分：1)
用户确实会将网址从地址栏直接复制并粘贴到电子邮件，博客等中，并将其保存在书签中，等等。
插件，甚至其他软件，例如窗口属性（备用shell，主题管理器，辅助功能软件）等内容都可能最终得到信息。例如，他们可能会崩溃并自动将故障转发给他们的开发人员。
远比keloggers复杂的蠕虫 - 就像采取screendump的东西 - 可以通过这种方式获得密码。有时甚至是安全软件，例如，如果部署在公司网络中。
如果用户有本地代理，那么他们可能正在与代理进行明文通信，代理又用SSL进行通信（不是它应该完成的方式，但它会发生）。
由于这些以及更多原因，带有用户名和密码的URL（以前是标准的 - 例如带有权限段中用户名和密码的ftp URL）现在通常被浏览器禁止。
http://tools.ietf.org/html/rfc3986#section-7.5
所以，强调不，不要这样做。
答案 3 :(得分：0)
不提供用户名和密码等精致信息总是很好的编程实践 在URL中。无论网站有多好，它都可能受到损害。那么为什么要提供更多信息？