2010-05-19 48 views
1

如果缺少必需的querystring参数并让global.asax将其与Application_Error一起捕获,然后将用户转移到错误页面,是否有任何问题导致asp.net页面抛出(自定义错误)?我有几个执行这些检查的基类,我不确定将错误传达给用户的最佳方式。确定为丢失的所需查询字符串参数抛出错误?

所以,这样的事情:

int reqParam; 
if(!isParamSet("myReqParam", out reqParam)) 
{ 
    throw new QuerystringParamMissingException(); 
} 

,然后通过的Application_Error Global.asax中捕获。

另外,从安全角度来看,我应该向用户提供多少信息?只是这是一个错误,或者查询字符串参数丢失,或者缺少哪个参数,或者甚至是该参数指示的用途?

回答

3

这一切都取决于它的错误有多严重以及用户是否可以轻松地从错误中恢复。

一种观点是用户不应该能够进行无效调用 - 所有需要查询字符串的链接都应该在客户端进行验证,因此在网站的正常运行期间,所有查询都将是完整且有效的。因此,如果缺少参数将是一个严重的错误,因此引发异常是非常有效的方法。

如果你想阻止人们修改查询字符串以访问他们不应该访问系统的某些部分,这将会很有用。他们很可能错过一个参数,并显示一个自定义的错误页面可能不会给他们任何线索他们错了什么。

虽然你应该记录错误 - 所以至少你知道什么时候错了什么地方。

+0

我的主要目标是让人们避免使用查询字符串或复制粘贴querystring。我仍然没有确定向用户提供有关错误的多少信息(“所需的查询字符串参数丢失”或“必需的查询字符串参数XYZ丢失”)。但是,我打算记录错误。 你是什么意思“应该验证客户端”?如果他们想修改查询字符串,那么客户端代码会阻止它们? – balazs 2010-05-19 12:17:51

+0

@Balazs - 我的意思是,在网站的正常运行中,不应该有可能产生一个无效的查询字符串,所以缺少的参数确实是一个例外情况。 – ChrisF 2010-05-19 12:24:57

+0

Gotcha。感谢您的澄清。 – balazs 2010-05-19 12:27:08

2

只要您不相信这种情况会出现在正常的应用程序使用情况下,这是一个可接受的解决方案。

通过让异常出现在堆栈上,您将无法从错误中恢复,在这种情况下,您可能无法恢复。

0

我相信你不应该让你的应用程序抛出一个错误,只要你能控制这种情况。我的意思是既然你知道什么参数可能会丢失......所以你可以提示用户输入,而不是抛出错误,然后让应用程序处理剩下的情况。

而是提供一个用户友好的信息,并帮助用户了解出了什么问题!

谢谢, 保重。

+0

除了提示用户查询字符串值(特别是对于具有相当神秘值的参数),不是特别实用的事情。这里的关键是我无法控制情况。如果缺少必需的参数,那么我就无能为力了。我能做的最多的事情是将它们转移到一个错误页面,让他们知道有错误,也许告诉他们这是一个缺少查询字符串参数错误,也许可能告诉他们哪些参数丢失。 – balazs 2010-05-19 12:25:23

0

您应该记录用户手动操作查询字符串然后重定向到默认页面(主页或登录页面)所导致的错误(您必须确定)。 当缺少的参数是由您的应用程序f.e引起的。没有完整的验证用户输入,那么你应该消除原因。

-1

请记住,抛出异常的性能成本。只是将页面重定向到错误页面&来处理错误而不会引发异常,性能更高。

话虽这么说,这是方便,只是抛出一个异常,因为有很多的配置,以及在ASP.NET内置机制处理异常,例如:

HttpContext.Error 
HttpContext.AllErrors 
HttpContext.IsCustomErrorEnabled 
<customErrors defaultRedirect="..."> node in the web.config