为什么 FullAjaxExceptionHandler 不简单地执行 ExternalContext#redirect()? [英] Why FullAjaxExceptionHandler does not simply perform an ExternalContext#redirect()?

查看:20
本文介绍了为什么 FullAjaxExceptionHandler 不简单地执行 ExternalContext#redirect()?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在 OmniFaces 中,FullAjaxExceptionHandler 在找到要使用的正确错误页面后,调用JSF 运行时构建视图并呈现它,而不是包含 AJAX 调用的页面.

In OmniFaces, the FullAjaxExceptionHandler, after having found the right error page to use, calls the JSF runtime to build the view and render it instead of the page that includes the AJAX call.

为什么会这样?恕我直言,只执行 ExternalContext#redirect() 会更简单吗?这样做有什么具体原因吗?

Why this? IMHO it would be simpler to just perform a ExternalContext#redirect()? Are there specific reasons to do this?

我们正在基于 FullAjaxExceptionHandler 编写自己的 ExceptionHandler 并想了解这种设计背后的原因.

推荐答案

FullAjaxExceptionHandler 的主要目标是让 ajax 请求期间的异常完全表现得与非 ajax 请求期间的异常.开发人员必须能够在两种情况下重用错误页面,而不必担心在实现错误页面时出现的情况.

The primary goal of the FullAjaxExceptionHandler is to let exceptions during ajax requests to behave exactly the same as exceptions during non-ajax requests. The developer must be able to reuse the error pages across both conditions without worrying about the condition while implementing the error pages.

在非 ajax 请求期间,重定向不是正常流程的一部分. 中的默认 机制执行转发以显示错误页面,而不是重定向.如果执行了重定向,则所有错误页面请求属性(例如 javax.servlet.error.exception)都将丢失并呈现为 null.此外,通常的做法是将错误页面放在 /WEB-INF 中,以防止最终用户能够直接访问(并添加书签和共享)它们.重定向将要求它们可公开访问,这表明存在主要设计问题(意图的目标页面实际上是一个真正的错误页面?).

A redirect isn't part of the normal flow during non-ajax requests. The default <error-page> mechanism in web.xml performs a forward to display the error page, not a redirect. If a redirect was performed, all error page request attributes such as javax.servlet.error.exception would get lost and render as null. Moreover, normal practice is to place error pages in /WEB-INF to prevent endusers from being able to directly access (and bookmark and share) them. A redirect would require them to be publicly accessible, which indicates a major design problem (is the intented target page actually a real error page?).

如果您确实需要执行到/从错误页面的重定向,请自行开发一个自定义异常处理程序,该处理程序显式调用 ExternalContext#redirect() 并且不使用 web.xml 机制,或者添加一个 到相关错误页面的 HTML 标题(此处的示例).

If you really need to perform a redirect to/from your error page, either homegrow a custom exception handler which explicitly invokes ExternalContext#redirect() and doesn't utilize web.xml <error-page> mechanism, or add a <meta http-equiv="refresh" ...> to the HTML head of the error page in question (example here).

如果您确实打算在发生 ViewExpiredException 时重定向到某个登录页面,那么您应该意识到用户未登录"和用户未登录"的情况之间存在很大差异.和会话/视图已过期".对于前者,您根本不应该捕获 ViewExpiredException,而是使用简单的 servlet 过滤器,它检查用户是否登录并相应地重定向,早在 FacesServlet 被调用之前.普通的身份验证框架(JAAS、Shiro、Spring Security 等)也可以这样工作.

In case you actually intended to redirect to some login page when a ViewExpiredException occurs, then you should realize that there's a big difference between the cases of "User is not logged in" and "Session/view is expired". For the former, you should not be catching ViewExpiredException at all, but use a simple servlet filter which checks if the user is logged in and redirect accordingly, long before the FacesServlet is invoked. A normal authentication framework (JAAS, Shiro, Spring Security, etc) also works that way.

这篇关于为什么 FullAjaxExceptionHandler 不简单地执行 ExternalContext#redirect()?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆