# Null desktop id results in error 467:Unknown

cvarona
554 1 6

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;
}

-it does not happen if I click on other fields which do not display any watermark
-triggers that would usually do something (menu options, buttons) do nothing (they just don't get activated).

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

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

delete retag edit

## 5 Replies

benbai
2228 6
http://www.zkoss.org

Hi César,

Could you provide a sample that can reproduce this issue for further investigating?

Regards,
Ben

cvarona
554 1 6

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

cvarona
554 1 6

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();

// 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.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
response.setContentLength(0);
response.flushBuffer();

return;
}
}

filterChain.doFilter(servletRequest, servletResponse);
}

And it does, for the time being. I hope this turns out to be helpful for somebody.

With kind regards

César Varona

benbai
2228 6
http://www.zkoss.org

Hi César,

Best Regards,
Ben

sousa1981
573 4

Hi, Can you post your web.xml and completely ntlm filter class, please. I didn't understand " I've set up a filter before the zkau servlet".

[hide preview]