在 ASP.NET 2.0 中隐藏查询字符串答案

【问题标题】：Hiding Querystring in ASP.NET 2.0在 ASP.NET 2.0 中隐藏查询字符串
【发布时间】：2013-07-15 21:20:39
【问题描述】：

我们的网站由我们称为“Start.aspx”的 3 个主要页面组成，然后是一个内容 iframe，用户可以在其中进行几乎所有的网站交互。

不过，最近，我不得不实现在不同产品的 Start.aspx 页面之间跳转并自动将内容 iframe 更改为指定页面的功能。

实际的功能工作得很好，但我们遇到的问题是完整的查询字符串被暴露了。因为我们在内容 iframe 中加载所有页面，所以在常规站点使用期间页面 URL 保持在“Product/Start.aspx”。

但是，这个新功能将查询字符串传递给 Start.aspx（它具有适当的解析器来在内容 iframe 中加载请求的页面），我们需要将该 URL 保持为“Start.aspx”。

到目前为止，我已经研究了URL Rewriting，因为每个产品的着陆页都是“[Product]/Start.aspx”，所以它会抛出错误。我查看了不同的URL Rewriting 解决方案，以及ScottGu's blog post on routing。

问题在于这些解决方案似乎用于简化导航，例如将“Blogpost.aspx?Year=2013&Month=07&Day=15”转换为“Blogpost.aspx/2013/07/14”这不是我们想要的。我们并不是想通过 URL 简化导航，我们实际上只是想完全隐藏我们的查询字符串。

一旦内容 iframe 从初始查询字符串。我们不需要考虑每一页。我们只需要将其作为总体规则。 90% 的情况下它不会成为问题，因为大多数正在完成的工作不会在没有用户切换产品的情况下从一个产品跳到另一个产品（这是以专门使用“Response.Redirect（”）的方式完成的[产品]/Start.aspx")"。

一旦从 Querystring 参数加载了内容 iframe，我们就不再需要它们了。其余功能通过 iframe 运行，没有任何问题。

这是我想多了，还是我要求的东西不太可行？

【问题讨论】：

你为什么要隐藏查询字符串？如果您的内部框架有一个查询字符串，那么它仍然是公开的，只需额外点击即可获得它。
是的，你我都知道，但这是功能规范的一部分。
您能否让起始页使用 AJAX 进行附加查询，这样用户就不会总是看到新的 URL 是什么？除非他们使用 Fiddler、Wireshark 或其他东西来拦截流量。
嗯。也许是时候从 .NET 2.0 升级了？它现在大约八岁了。

标签： c# asp.net

【解决方案1】：

就字面上的“删除所有查询字符串字符”而言，仍然能够将查询字符串值传递到另一个页面，我认为这是不可能的。除非你在会话变量或类似的东西中这样做。

如果您只是担心敏感数据在查询字符串中以纯文本形式显示，则可以选择“加密”查询字符串：

http://www.codeproject.com/Articles/33350/Encrypting-Query-Strings

查询字符串仍将显示，但它将是“Product/Start.aspx?e0ayfefae0y0someencryptedmess108yfe0ayf0a”。接收查询字符串的页面将对其进行解密。所以查询字符串的功能是存在的，但最终用户不知道这些值。

【讨论】：

【解决方案2】：

由于您已将此标记为 ASP.NET 问题，我想说的方法是将导航数据保存在 Session 变量中。

【讨论】：

是的，这看起来也很直观，对吧？除了我们的领导强调使用 QueryString 参数而不是会话变量。
所以问题是，“如何在我的 Web 应用程序中使用 QueryString 参数而不让用户看到它们？”答案是，“你不能。”根据定义，它是 URL 的一部分。
是的，这就是我一直害怕的。我正在考虑找到一些摇摇欲坠的方法，让 iframe 在加载后将其父 URL 更改为“Start.aspx”或其他东西，因为它是一种美学的东西。
您也许可以模拟这种效果。但现在你说的是浏览器杂牌。无论您做什么，这都是一种非常脆弱和疯狂的解决方案。
好的，经过一番讨论，我的负责人说他关于会话变量的 kibosh 只是为了让我们的网站不是一堆不可调试的会话变量，我们的初级开发人员无法学习。它们应该可以很好地处理查询字符串信息。

【解决方案3】：

你能用 POST 代替 GET 吗？这样，数据就在表单中，而不是在查询字符串中。

作为旁注，隐藏参数以使 URL 看起来更漂亮并且可以添加书签是可以的。如果您出于任何安全原因这样做，那么它的安全性非常浅。对于用户来说，查看表单和查询字符串中传递的内容并更改和重新发布这些内容是微不足道的。安全需要主要在服务器端处理。

【讨论】：

绝对与安全无关。纯美学。这通常最终成为开发过程中最困难的部分。
所以也许 POST 是要走的路。查看forums.asp.net/t/1635835.aspx/1，了解有关将 iframe 从包含页面发布到另一个页面的讨论。