我有一个映射到/ *的过滤器，我的安全约束映射到/*.
当未配置应用程序（数据库中的条目）时，过滤器会向前执行请求。
当我访问应用程序时，我希望看到由j_securit_check提供的登录页面，而是执行过滤器并执行转发。由于我从未进入登录页面，因此以循环结束。
我认为在处理过滤器之前执行了安全检查？
这是WebSphere 8.0.0.4。它在Tomcat和JBoss下运行良好。
感谢阅读。
答案 0 :(得分：1)
根据我的理解，由于安全原因，您不应该拦截j_security_check调用。
听起来像是Webspehere中的一个错误（我用谷歌搜索过，这是旧版本的Websphere中的一个错误/功能，不确定8.0.0.4）
答案 1 :(得分：0)
您不能，但是您可以在j_security_check上映射过滤器以进行后验证处理，或者您可以编写自己的自定义登录模块或信任关联拦截器 请参阅此处的示例：http://www.ibm.com/developerworks/websphere/techjournal/1112_deluca/1112_deluca.html
答案 2 :(得分：0)
如果我将安全性约束映射到/ *然后将过滤器映射到/（没有通配符），则一切都按预期工作。
这是我从IBM获得的关于为什么在运行安全检查之前运行servlet过滤器的反应。
安全L3与Webcontainer团队的开发人员交谈。他说 首先运行servlet过滤器是WAD。 j_security_check是一个 Web资源，与所有Web资源请求servlet过滤器一样 将首先运行。所以这是对你关注的简短回答。 安全L3查看了请求流。似乎就是这样的 过滤器被编码，login.jsp结果永远不会返回给客户端， 因此永远不会有j_security_check。可以看出来了 过滤器做了 “的request.getRequestDispatcher（” 测试/测试page.jsp“）。向前（请求， 响应）;“。开发人员说，forward（）请求不是auth WAD，再次检查。因此，在重新设计时，请在minf中保留以下内容 servlet过滤器。
- 将在j_security_check或任何网站之前调用Servlet过滤器。
- 2使用request.getRequestDispatcher（）。forward（）禁用身份验证。
我不会重新设计我的过滤器，因为它在Tomcat或JBoss下运行时按预期工作。唯一需要改变的是web.xml中的映射。
答案 3 :(得分：0)
以下是IBM的另一个回复。他们建议从过滤器转发永远不会受到j_security_check的保护，因此在使用WebSphere时要小心。 Jboss和Tomcat的行为不一样。
web.xml显示[configFilter]映射到/ * 即 configFilter / *
并且安全性也映射到所有 即 General Auth。 / *
入站请求适用于[/rootFilter/test/test-page.jsp]，安全性为 调用然后将其重定向到[rootFilter / login.jsp]。 现在为请求[rootFilter / login.jsp]，自过滤器 [configFilter]]映射到所有请求， 执行[configFilter]将请求转发给 [/rootFilter/test/test-page.jsp]然后提供test-page.jsp。
根据13.2声明性安全性中的Java Servlet规范， 安全性对任何已分派的请求无效，因此转发 请求[/rootFilter/test/test-page.jsp]不检查安全性。
这是来自规范， 安全模型适用于Web的静态内容部分 申请和 应用程序中的servlet和过滤器 客户。该 当servlet使用RequestDispatcher时，安全模型不适用 调用 使用forward或include的静态资源或servlet。
客户需要研究要制作的应用程序的设计 确保过滤器未映射到所有请求或过滤器 不会转发到其他资源。