Ale*_*kov 1 apache internet-explorer tomcat ntlm single-sign-on
此处描述了类似的问题:GWT IllegalArgumentException:encodedRequest不能为空
我的GWT应用程序部署在Tomcat6中,它通过使用Coyote/JK2连接器与Apache链接.对于SSO,我使用mod_auth_sspi/1.0.4.
当我使用IE8时,页面不显示,但对于Firefox一切正常.在Tomcat日志中,我看到以下内容:
SEVERE: Exception while dispatching incoming RPC call
java.lang.IllegalArgumentException: encodedRequest cannot be empty
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:232)
at org.spring4gwt.server.SpringGwtRemoteServiceServlet.processCall(SpringGwtRemoteServiceServlet.java:32)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:643)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at gov.department.it.server.RequestInterceptorFilter.doFilter(RequestInterceptorFilter.java:90)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:311)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:776)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:705)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:898)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)
到目前为止我尝试了什么:
1)找不到注册表项DisableNTLMPreAuth(恕我直言,这不是解决方案,因为在我的情况下IE 8是主动使用的).
2)我已经安装并配置了本机Windows身份验证框架WAFFLE
web.xml中:
...
<filter>
<filter-name>NegotiateSecurityFilter</filter-name>
<filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
<init-param>
<param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
<param-value>NTLM</param-value>
</init-param>
</filter>
...
<filter-mapping>
<filter-name>NegotiateSecurityFilter</filter-name>
<url-pattern>/my-app/*</url-pattern>
</filter-mapping>
...
但它没有帮助.
3)在worker.properties我设定socket_keepalive=0,但它也没有帮助 -
worker.ajp13.type=ajp13
worker.ajp13.host=localhost
worker.ajp13.port=8009
worker.ajp13.lbfactor=50
worker.ajp13.cachesize=10
worker.ajp13.cache_timeout=600
worker.ajp13.socket_keepalive=0
worker.ajp13.socket_timeout=300
我还能尝试做些什么？我非常感谢这些信息.谢谢大家.
您已经重新发现了7年前的#1错误,mod_auth_sspi其中影响了众多项目,使众多开发人员感到沮丧,多年来造成了无数浪费的工时.然而它仍然没有得到解决,因为维护者并不认为它是一个bug.微软也没有针对旧浏览器解决这个问题,因为有迹象表明IE9没有这个问题.
原因
它是由IE尝试"智能"并发送零内容长度的POST(我将其命名0POST为尝试使其成为可转换术语以使那些在下一次重新发现它的人受益7年.)带有NTLM auth标头,期待受到服务器的挑战.IE在此保护空间中进行身份验证后执行此操作.所以它知道它会再次受到挑战.可悲的是,mod_auth_sspi并不像IE那么聪明,所以当0POST到达时,服务器端会发生不好的事情,并且它会在没有受到质疑的情况下通过应用程序.除非有时即使对于未受保护的区域,如果它们位于需要认证的区域下,也会发生这种情况.其他浏览器并不假装像IE那样聪明,并且不会尝试在第一次往返中为"性能"保存几个字节,因此它们不会遇到这个问题.以下是Microsoft对此行为的解释.
可怕的解决方法
在Apache httpd.conf中设置
SSPIPerRequestAuth On
这相当于您提到的DisableNTLMPreAuth IE客户端修复程序,这对于大型用户组来说是不切实际的.此外,它相当于削弱所有非Apache应用程序,可能能够处理0POST.实际上没有讨论这个设置的例子,或者在网上解释它的副作用,所以我将这个唯一的链接包含在我发现的内容中.无论如何,让一个服务器端改变似乎是两个邪恶中较小的一个.虽然现在,通过更改服务器配置,您已经削弱了访问此站点的所有其他无辜浏览器.
此解决方法的问题在于它强制每个请求执行SSPI握手,这会导致大量额外的401流量并可能影响性能.对于性能,NTLM身份验证被视为"基于会话"而非"基于请求",这意味着握手仅在会话开始时发生.使用此设置时,还应设置过滤器以防止日志填满401.另请注意,这需要打开KeepAlive.
我不确定您的设置是否与WAFFLE修复中描述的设置相同; 他们像你一样使用Apache吗？我认为WAFFLE适用于Tomcat,而前面有Apache,所以Apache正在处理身份验证.您可以考虑使用该设置而不是Apache.如果您可以使用该设置,那么它可能是比此解决方案更好的选择,因为WAFFLE已经明确地考虑了0POST并且可以处理它.作者在与GWT合作时也发现了这个宝石.
有趣的是,对于jcifs,9年前发布了针对这个问题的解决方案 .作者后来还提供了一个很好的解释:
过滤器中的代码检查所有HTTP POST请求,并确定它们是否包含NTLM类型1消息.如果请求包含NTLM类型1消息,则过滤器响应虚拟类型2消息以满足IE在提交任何POST数据之前重新协商NTLM的愿望. 然后,浏览器应该响应NTLM类型3消息以及过滤器应该允许链接到Web应用程序其余部分的帖子数据.
如果您有兴趣,5年前还为mod_auth_sspi创建了一个简单的补丁.在作者自己的回购中看到差异.我不确定我是否同意这种方法.它试图检测IE/0POST,而我认为正确的修复应该是检测客户端是否正在使用NTLM Type 1标头请求auth,如jcifs过滤器.(类型1只是意味着它是握手的第一条消息)
我不知道是否有人已经在使用替代品来mod_auth_sspi想mod_auth_ntlm_winbind,如果他们不出现此行为.如果有,请发表评论.我们已经知道WAFFLE有效,但它不是mod_auth_sspi的替代品.
另一种方法是忘记NTLM并使用Kerberos,(mod_auth_kerb)但很多人发现设置太复杂了.IE将在任何质询 - 响应方案上以这种方式运行,因此很可能curb auth可能遇到同样的问题,因为在两种情况下都会发生类似的401序列.但作为一个不同的模块,它有可能处理这个问题.
最后,我应该提一下,还有另一个问题,即每个请求的auth解决方法似乎没有解决.我没有看到它在任何地方讨论过,但我发现有时在0POST之后,服务器等待很长时间才能用(正确)POST的结果响应最后的200响应.这种长时间延迟仅在最后发生,而不是立即响应0POST.这很好,握手完成,但服务器没有响应,直到经过漫长的等待,我注意到可疑接近90秒,就像某种超时.实际结果是,当用户登录时,IE8有时会挂起90秒等待服务器响应.我以为KeepAlive可能会导致它,但它甚至没有在我的配置中明确定义,所以我认为它是在15秒Apache默认值.但我确信这与0POST有关,因为它仅在成功进行0POST授权握手后才会发生.我们的服务器位于防火墙的单独(双向)可信域中,因此可能与它有关.
这个问题的不同例子
最热闹的例子是IE的智能如何影响微软自己的产品!他们自己无法理解如何处理IE的行为,导致ISA Server 2006中的错误.
| 归档时间： |
|
| 查看次数： |
7548 次 |
| 最近记录： |