-
FEATURED COMPONENTS
First time here? Check out the FAQ!
Hi,
I'm having trouble with a zk 6.0.1 application; these are the symptoms:
-when I click on a field displaying a watermark a popup saying (467: Unknown) and offering both ok and cancel options appears once and again, no matter which option is chosen.
-by debugging I can see the execution enters the following if:
if (dtid == null) { //Bug 1929139: incomplete request (IE only) if (log.debugable()) { final String msg = "Incomplete request\n"+Servlets.getDetail(request); log.debug(msg); } response.sendError(467, "Incomplete request"); return; }
My environment consists of just one server; I've set up a Stingray balancer and ntlm authentication. The problem described above happens if I try to access the balancer's url using ie. It does not happen if I
-directly access the server's url
-apply some authentication method other than ntlm
-use google chrome
Any idea as to what might be happening? And if not, would it be possible to write a filter that detects a certain zkau request is going to end up yielding 467 so that I can discard it rather than let the dhtml update server process it? (I've already tried the rather naïve approach of checking for the presence of dtid, but when I do so wpds do not get loaded).
With kind regards
César Varona
Hi César,
Could you provide a sample that can reproduce this issue for further investigating?
Regards,
Ben
Hi Ben,
thanks for your interest; I'm afraid it's not that easy. I'll try to build something that can help you reproduce this issue, but the environment itself is not easy to mimick. Unless you can set up a Stingray balancer and a domain with next-to-medieval NTLM1 authentication, you're done. And anyway, I don't think zk is to blame for this, rather our environment is. That's why I think it's more feasible to write a filter that detects and discards these 467. It's only that I don't know exactly what dtid-lacking requests to ignore.
With kind regards
César Varona
Hi again Ben,
I've finally managed to understand (only to a certain extent) what is happening and how to solve it.
The source of the problem lies on the rather obsolete ntlm authentication mechanism. After recovering the code of the old spring ntlm filter and adapting it to the latest spring api, I set it up in order to perform authentication. However, it looks like it's no good idea to use ntlm to authenticate ajax applications running on IE. As Bill Comer explains:
However the are atleast two scenarios where this fails.
1) When the session is timed out and a form.submit() request is made.
Under this situation a windows logon box is presented. This is obviously not desirable in a SSO project.
2) If the page makes heavy use of dwr/javascript.
In this case the page makes repeated NTLM authentication requests and stack traces are observed with the message 'This is not a Type 3 Message'.
Bill Comer's second case refers to spurious POST ntlm authentication requests being sent over and again. In my environment these request where targeted at /zkau, but only when the Stingray balancer was working (I've failed so far to find out the reason why this happens).
In order to get rid of these ntlm post request, I've set up a filter before the zkau servlet containing the code he provides:
public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { // Converting servlet request to http servlet request HttpServletRequest request = (HttpServletRequest) servletRequest; HttpServletResponse response = (HttpServletResponse) servletResponse; // Retrieve http session final HttpSession session = request.getSession(); final String authMessage = request.getHeader("Authorization"); // Check the special IE POST request with Authorization header containing // type-1 message (see method javadoc) if (reAuthOnIEPost(request) && authMessage != null && authMessage.startsWith("NTLM ")) { logger.debug("POST Request with NTLM Authorization detected."); // decode the NTLM response from the client byte[] src = Base64.decode(authMessage.substring(5)); // see if a type 1 message was sent by the client if (src[8] == 1) { logger.debug("NTLM Authorization header contains type-1 message. Sending fake response just to pass this stage..."); Type1Message type1 = new Type1Message(src); // respond with a type 2 message, where the challenge // is null since we don't care about the server response // (type-3 message) since we're already authenticated // (This is just a by-pass - see method javadoc) Type2Message type2 = new Type2Message(type1, new byte[8], null); String msg = Base64.encode(type2.toByteArray()); response.setHeader("WWW-Authenticate", "NTLM " + msg); response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); response.setContentLength(0); response.flushBuffer(); return; } } filterChain.doFilter(servletRequest, servletResponse); }
With kind regards
César Varona
Hi César,
Thanks for your sharing.
Best Regards,
Ben
Asked: 2012-07-09 15:53:49 +0800
Seen: 283 times
Last updated: Feb 15 '18