不向不正确使用网站的用户提供优雅的错误是不是很糟糕？
我最近收到一位同事关于我的网站源代码的反馈。他说，不优雅地处理视觉界面不允许做的事情是一种不好的做法。
由于不是很清楚，所以举个例子。
假设访客可以发表评论。
- 评论将保存到数据库的
nvarchar(500)列中。 字段长度限制为 500。
但是，当然，没有什么可以禁止更高级的用户禁用长度限制并输入 501 个字符。
（其他示例：提交一个
如果访问者这样做，则会在代码合约级别出现故障。 AJAX 请求将因意外错误而失败（或者，在页面提交时，将出现意外错误）。在所有情况下，访问者都会看到发生了错误，但不会收到优雅的消息来表明提交的评论长度太长。
为什么这是不好的做法？为什么我要为正确使用网站的访问者永远不会出现的情况设计清晰明确的错误消息呢？
注意：我知道，当发生类似情况时，显示 .NET Framework 详细错误和堆栈跟踪很糟糕。如果我这样做，这将是一个严重的安全问题。但就我而言，只有一个 AJAX 响应，其中包含一些非常通用的内容，或者重定向到一个通用页面，并对错误表示歉意。
I recently received a feedback from a colleague about my source code of a website. He says that it is a bad practice to not handle gracefully what visual interface does not allow to do.
Since it's not very clear, here's an example.
Let's say a visitor can comment something.
- A comment is saved into a database, in a
nvarchar(500)column. - The
<input />field length is limited to 500.
But, of course, nothing forbids to a more advanced user to disable the length limit and to type 501 character.
(Other examples: submitting an option which does not even exist in a <select />. But there is a graceful error when the user is asked to enter a number, and she enters a non-number instead, since keypress events are controlled through JavaScript, and JavaScript may be disabled)
If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). In all cases, the visitor will see that something wrong happened, but will have no graceful message indicating that the length of the submitted comment is too long.
Why is it bad practice? Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?
Note: I understand that it sucks to display a .NET Framework detailed error and a stack trace when something like this happens. If I do so, it's a serious security issue. But in my case, there is just an AJAX response with something very generic or a redirect to a generic page with the apologizes about an error.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
由于每个人似乎都错过了您的实际问题，所以我将放入我的 2c （尽管毫无疑问我会被否决以进行报复）
只要您的输入经过服务器端验证（您的客户端最大长度可能没问题，尽管有些不起眼的浏览器可能不支持它），您可以返回通用错误消息，只要它不包含异常信息（您已声明不包含异常信息）。
但是，如果由于缺少 javascript 或输入不正确而可能导致验证失败，那么为了用户的理智，应该提供自定义错误消息。
简而言之，你正在做的事情很好。
Since everyone appears to be missing your actual question, I'll put in my 2c (though I'll no doubt be downvoted in retaliation)
As long as your inputs are validated server side (your client-side maxlength is probably ok, though some obscure browsers may not support it), you can return a generic error message as long as it contains no exception information (which you have stated it doesn't).
If, however, it's possible to fail validation via lack of javascript or incorrect entry, then a custom error message should be provided for the sake of the user's sanity.
In short, what you are doing is fine.
首先，最重要的是
您应该验证用户在服务器上提供的所有内容！这意味着不让 501 字母通过
除此之外，如果发生未处理的异常，您应该向用户显示一条消息，不会透露任何内容。如果您要返回异常信息，那么这对攻击者来说就是金粉。
最好的方法是显示一般错误，例如“很抱歉，我们正在立即解决该问题”，并将异常信息通过电子邮件发送给开发人员，以便他们修复它。
First an most importantly
You should validate everything the user supplies on the server! This means not letting 501 letters through
Other than that if an unhandled exception occurs you should show the user a message which gives nothing away. If you were to return exception information this is gold dust to an attacker.
The best method is to display a general error such as "We're sorry, we're working on the problem straight away" and e-mail the exception information to the developers in order for them to fix it.
如果每个人都正确使用网络，我们就永远不需要验证。
正如罗纳德·里根曾经说过的那样，“信任，但要核实”。
对字段长度进行服务器端验证。进行验证以确保不存在任何 XSS 或 SQL 注入攻击。您需要担心的不是那些正确使用您网站的人，而是那些恶意使用您网站的人。
If everyone used the web correctly, we'd never need to have validation.
As Ronald Reagan once said, "Trust, but verify".
Put in server-side validation for the length of fields. Put in validation to make sure there aren't any XSS or SQL Injection attacks. It's not the people who use your site correctly that you have to worry about, it's the ones that use it maliciously.
我认为问题的最大部分是您假设验证应该只发生在 UI 中。最好在 UI 和后端中进行验证。无需返回堆栈跟踪或详细的异常信息。在 Page_Load() 上，您应该始终再次验证所有用户输入并静态显示信息，就像用户禁用了 JavaScript 一样。
I think that the largest part of the problem is that you are assuming that validation should only be happening in the UI. It really is best to validate in the UI and the backend. There is no need to return a stack trace or detailed exception information. On Page_Load(), you should always be validating all user input again and displaying the information statically, as if the user has disabled JavaScript.
您所描述的不仅仅是糟糕的实践，而且是糟糕的设计。如果您可以预见到错误或异常，那么您应该预见到处理它、减轻它或减轻它的方法。这适用于任何界面设计，无论是网站还是冰箱。如果访问者遇到一般性错误并且不知道如何修复它，那么该人为什么要费心使用您的网站呢？如果他们被迫这样做（可能是出于工作原因），那么您所做的就是疏远您的客户并给自己带来坏名声。
我建议你问问自己为什么不处理这些很容易控制的情况。是懒惰还是你只是缺乏作为用户的经验？
What you're describing isn't just bad practice, it's bad design. If you can anticipate an error or exception, then you should anticipate methods of handling it, mitigating it or alleviating it. This goes for any interface design whether it's for a website or a refrigerator. If a visitor gets a generic error and is given no insight as to how to fix it, then why should that person bother using your website? If they're forced to (for work reasons maybe), then all you've done is alienate your customer and give yourself a bad name.
I would suggest you ask yourself why you're not handling these very easy to control situations. Is it laziness or do you just lack experience as a user?
服务器端验证有两个主要目的：
如果客户端验证由于某种原因不起作用，则作为优雅的降级
作为一种安全措施，以确保恶意客户端不会损坏您的系统。< /p>
如果您想采取真正的优雅降级路线，那么如果服务器仍然为每次验证返回给用户一条友好的消息，那就太好了。
在 maxLength 的情况下，这不太可能需要。但是很多类型的验证都使用Javascript，并且仍然有一些人或平台不支持Javascript。较旧的移动平台将是这里的主要嫌疑人。
然而，如今，我们大多数人都认为 Javascript 是可以信赖的，因此如果服务器验证失败，显示通用错误消息就可以了。
Server side validation is for two main purposes:
as a graceful degradation if the client validation doesn't work for some reason
as a security measure to ensure malicious clients can't damage your system.
If you want to take the route of true graceful degradation, it would be NICE if the server still gave back the user a friendly message for each validation.
In the case of maxLength, this is not very likely to be needed. But many kinds of validation use Javascript, and there are still those people or platforms that don't support Javascript. Older mobile platforms would be the main suspects here.
However, these days, most of us assume that Javascript can be relied on, so a generic error message if server validation fails is fine.