我们有一个绝对需要 JavaScript 才能运行的表单，并且验证是在客户端完成的。验证也在服务器端执行，但是当服务器端验证失败时让它显示错误将是一项极端的工作。
既然用户没有机会没有 JavaScript，那么是否可以只因 HTTP 错误而失败？他们无法通过服务器端验证的唯一方法是他们要么是恶意用户，要么不能使用 JavaScript，在这种情况下，他们无论如何都不会使用表单。
谢谢
问问题
82 次
4 回答
2
我说这很好，除了某些类别的错误。
一些验证错误不是恶意的结果，而只是在实际处理表单时无法检查和发现。这可能是因为需要保留但不能保留的稀缺资源（“此用户名已在使用中”），或者由于某些服务器端可恢复错误（“上游信用卡处理器没有响应。请重试之后”）。对于这些类型的错误，您绝对应该将某种错误消息传达给用户。很难想象一种设计不可能将这些类型的错误发回。至少你可以这样做：
- 发送您的 HTTP 错误响应（4xx 或 5xx，具体取决于错误的性质）
- 在您的响应正文中，将错误消息打包到您的 javascript 可以轻松理解的某些数据结构中。（JSON 或 XML，甚至 text/plain！记得设置 mime 类型。）
- 让 javascript 请求的错误处理程序将错误文本插入表单的可见位置（例如，在顶部或提交按钮附近）。
然而，最重要的是要有服务器端验证而不信任客户端。你已经在这样做了，所以如果你想进一步做任何事情，那就是润色和创造最佳用户体验的问题。有时这需要不成比例的努力，这没关系。
于 2011-12-19T01:47:02.790 回答
0
我个人认为还不错。
特别是如果在没有 Javascript 的情况下使用该网站的前一步也根本无法工作，因此用户在没有 Javascript 的情况下无法继续访问相关页面，那么在没有 Javascript 的情况下使其工作的巨额费用是浪费精力。例如，在 .Net 网络表单中，登录需要 Javascript，因此在我看来，网站安全区域内的任何页面都可以假定 Javascript 可用。
不过，我很好奇其他人的想法。
于 2011-12-19T01:31:34.560 回答
0
如果 HTTP 请求失败的唯一预期用例是当有人绕过浏览器时，那么 HTTP 请求失败似乎完全没问题。您不会影响任何预期的用户场景，但您仍然通过服务器端验证来保护服务器端的完整性。做更多的工作没有意义。对我来说似乎很好。
值得做更多工作来显示来自服务器的错误 UI 的原因是，如果存在错误数据会通过服务器的实际合法用户场景。但是，既然您认为合法场景不太可能或不可能到达那里，那么没有理由做这些额外的工作。
于 2011-12-19T01:46:23.757 回答
0
只要您确定客户端验证和服务器端验证是等效的，就可以了。关于这一点，我发现让客户端验证代码和服务器端验证代码保持同步有些麻烦（特别是如果它们是用不同的语言编写的，如果你不使用 node.js 或 GWt，情况总是如此）。如果有人有任何解决方案，那就太好了。
但是，如果某些验证只能在服务器端执行（例如数据库唯一性约束），那么向用户显示他们的客户端操作失败是很重要的。不过，这取决于应用程序本身。
于 2011-12-19T01:49:55.917 回答