0

Javascript error

asked 2018-02-14 01:37:58 +0800

sousa1981 gravatar image sousa1981
573 4

In some browsers, we are having this error constantly. Can anyone give a clue why?

We are using latest ZK Version.

The server failed to process your request. Try again? (467: 467)

delete flag offensive retag edit

8 Answers

Sort by ยป oldest newest most voted
0

answered 2018-02-14 01:51:48 +0800

sousa1981 gravatar image sousa1981
573 4

Looks like the issue is similar http://forum.zkoss.org/question/9851/zk-and-mod_jk/

link publish delete flag offensive edit
0

answered 2018-02-14 19:12:31 +0800

cor3000 gravatar image cor3000
3907 1 7
ZK Team

error 467 usually happens when an ajax request arrives at server side without providing the required POST data such as desktop ID.

https://github.com/zkoss/zk/blob/80bab4002def60d3f3f97ca3bcb2c746c9fe4dbb/zk/src/org/zkoss/zk/au/http/DHtmlUpdateServlet.java#L535-L542

This sometimes happens if redirects don't include the request body. Or if incorrect requests are sent to the ajax servlet (/zkau), please check your network traffic for unexpected redirects or truncated requests.

A useful tool for capturing the network activity is e.g. Fiddler

If you can provide some information about which request/redirect sequence causes this error we might be able to help.

link publish delete flag offensive edit
0

answered 2018-02-16 17:27:30 +0800

sousa1981 gravatar image sousa1981
573 4

I was thinking that it is related to http://forum.zkoss.org/question/9851/zk-and-modjk/ but even when we removed modjk it is still under problem.

We are sure now that it has direct relation with the following code, which does NTLM Authentication and only in IE.

Is there any clue/tip for it? We are going to make small project so we can share it here.

    <filter>
        <filter-name>ntlmv2-auth</filter-name>
        <filter-class>filter.NtlmFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>ntlmv2-auth</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

public void doFilter(ServletRequest req, ServletResponse res, FilterChain filterChain) throws IOException, ServletException {
    HttpServletRequest request = (HttpServletRequest) req;
    HttpServletResponse response = (HttpServletResponse) res;

    LOG.info("Page|" + request.getRequestURL() + "|");

    // Type 1 NTLM requests from browser can (and should) always immediately
    // be replied to with an Type 2 NTLM response, no matter whether we're
    // yet logging in or whether it is much later in the session.

    HttpSession session = request.getSession();

    String authorization = request.getHeader("Authorization");

    NtlmUserAccount ntlmUserAccount = (NtlmUserAccount) session.getAttribute(NTLM_USER_ACCOUNT);

    if ((ntlmUserAccount == null || StringUtils.isBlank(ntlmUserAccount.getUserName())) && authorization != null && authorization.startsWith("NTLM")) {
        Cache cache = singletonManager.getCache(CACHE_NAME);
        byte[] src = Base64.decode(authorization.substring(5));

        if (src[8] == 1) {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Create server challenge...");
            }

            byte[] serverChallenge = new byte[8];

            BigEndianCodec.putLong(serverChallenge, 0, SecureRandomUtil.nextLong());

            byte[] challengeMessage = ntlmManager.negotiate(src, serverChallenge);

            authorization = Base64.encode(challengeMessage);

            response.setContentLength(0);
            response.setHeader(HttpHeaders.WWW_AUTHENTICATE, "NTLM " + authorization);
            response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
            response.flushBuffer();

            synchronized (cache) {
                if (LOG.isDebugEnabled()) {
                    LOG.debug("Cache server challenge for: " + request.getRemoteAddr());
                }
                Element element = new Element(request.getRemoteAddr(), serverChallenge);
                cache.put(element);
            }

            // Interrupt filter chain, send response. Browser will
            // immediately post a new request.

            return;
        }

        byte[] serverChallenge = null;
        synchronized (cache) {
            Element challengeHolder;
            try {
                if (LOG.isDebugEnabled()) {
                    LOG.debug("Get cached server challenge for: " + request.getRemoteAddr());
                }

                challengeHolder = cache.get(request.getRemoteAddr());
                serverChallenge = (byte[]) challengeHolder.getValue();
            } catch (CacheException e) {
                // Something went wrong - just log it and start again
                if (LOG.isWarnEnabled()) {
                    LOG.warn("No challenge found in cache for client: " + request.getRemoteAddr());
                }
            }
        }

        if (serverChallenge == null) {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Start NTLM login...");
            }

            sendWwwAuthenticateResponse(response);

            return;
        }

        try {
            if (LOG.isDebugEnabled()) {
                LOG.debug("Try authenticating user now...");
            }

            ntlmUserAccount = ntlmManager.authenticate(src, serverChallenge);

            if (LOG.isDebugEnabled()) {
                LOG.debug("Authentication was successful. Creating session.");
            }

            session.setAttribute(NTLM_USER_ACCOUNT, ntlmUserAccount);
        } catch (Exception e) {
            LOG.error("NTLM authentication failed: " + e, e);
        } finally {
            synchronized (cache) {
                cache.remove(request.getRemoteAddr());
            }
        }

        if (ntlmUserAccount == null) {
            // No NTLM user in session yet, or authentication failed
            sendWwwAuthenticateResponse(response);
            return;
        }

        if (LOG.isDebugEnabled()) {
            LOG.debug("NTLM remote user " + ntlmUserAccount.getUserName());
        }

        session.setAttribute(Constantes.LOGGED_USERNAME, ntlmUserAccount.getUserName());
    }

    if (ntlmUserAccount == null) {
        if (LOG.isDebugEnabled()) {
            LOG.debug("No NTLM user set yet, begin authentication...");
        }

        sendWwwAuthenticateResponse(response);
        return;
    }

    if (LOG.isDebugEnabled()) {
        LOG.debug("NTLM user in session: " + ntlmUserAccount.getUserName());
    }

    HttpServletRequest filteredReq = null;
    if (!(request instanceof NtlmV2HttpRequestWrapper)) {
        // Wrap original request only once
        filteredReq = new NtlmV2HttpRequestWrapper(request, ntlmUserAccount.getUserName());
    }

    LOG.info("AFTER LOGGED_USERNAME|" + (session != null ? session.getAttribute(Constantes.LOGGED_USERNAME) : "") + "|");

    if (filteredReq != null) {
        filterChain.doFilter(filteredReq, res);
    } else {
        filterChain.doFilter(request, res);
    }
}

/**
 * @param response
 * @throws IOException
 */
private void sendWwwAuthenticateResponse(HttpServletResponse response) throws IOException {
    response.setContentLength(0);
    response.setHeader(HttpHeaders.WWW_AUTHENTICATE, "NTLM");
    response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    response.flushBuffer();
}
link publish delete flag offensive edit
0

answered 2018-02-21 12:59:30 +0800

cor3000 gravatar image cor3000
3907 1 7
ZK Team

The filter mapping pattern /* looks like it also affects requests to /zkau (which zk uses for AJAX requests). If those are blocked and retried again (after login) without sending the full original request body the 467 error will happen.

Still I can't run your code or fully parse (in my head) what's happening there.

I could imagine a scenario where a user gets logged out via NTLM and then clicks a button in the ZK application - triggering an AJAX request. Since redirecting to a login page usually don't make any sense from an AJAX request sending an SC_UNAUTHORIZED (ERROR-401) sounds good.

The question is what happens then or what would you like to happen in such a scenario? Usually ZK's client engine should report the ERROR-401 (which is possible to handle via custom client side code in JS). So there must be something happening which you haven't shared yet, or you are yet unaware of.

Tracing the network should give such insight about WHICH request gets handled HOW. As long as the request body is not changed it will work, so something changes the request body.

Sorry this is getting more complicated on your side. Inside ZK the error is quite clear: Something didn't arrive (the dtid or the whole request body). And where/why this happens is outside the scope of ZK.

link publish delete flag offensive edit
0

answered 2018-02-21 13:02:55 +0800

cor3000 gravatar image cor3000
3907 1 7
ZK Team

I found this maybe related discussions about AJAX/POST requests in combination with NTLM http://samba.2283325.n4.nabble.com/NTLM-Ajax-POST-td2512538.html

Maybe it gives some insight on why things are happening with your current setup.

link publish delete flag offensive edit
0

answered 2018-02-21 13:41:02 +0800

sousa1981 gravatar image sousa1981
573 4

Hi, We are going to provide complete very simple and small project, where you can reproduce on your side. I believe until tomorrow we can provide it. We need NTLM integration to automatically get username on IE for users. We stopped expand the software due to this problem.

link publish delete flag offensive edit
0

answered 2018-02-21 13:43:48 +0800

sousa1981 gravatar image sousa1981
573 4

Hi, We are going to provide complete very simple and small project, where you can reproduce on your side. I believe until tomorrow we can provide it. We have also reduced the filter mapping only to first login page, but error continues, that is strange, because error happens later when you stay a little bit (5 seconds) after login and go to an menu! We need NTLM integration to automatically get username on IE for users. We stopped expand the software due to this problem.

link publish delete flag offensive edit
0

answered 2018-02-23 10:54:13 +0800

cor3000 gravatar image cor3000
3907 1 7
ZK Team

updated 2018-02-26 11:11:49 +0800

The cause for the problem is the NTLM pre-authentication request which POSTs an empty request body (as described in this document ... below the 6 points it mentions the special case for POST requests). What this actually implies lies outside the scope of ZK. Such an empty request body should not arrive in the ZK application in the first place (ZK does the only thing it can do ... responding with an error indicating the missing request body - 467 - Request Incomplete).

Instead the NTLM protocol needs to be followed by responding with a Type II message ... (I don't know what the protocol does in detail) so I can't help with that, and an NTLM expert should be consulted.

Maybe an alternative NTLM integration from the list mentioned in the Tomcat Wiki helps to handle NTLM pre-authentication in the correct way. (Top of the list being Waffle)

Other people having the same question on stackoverflow provide alternative approaches.

link publish delete flag offensive edit
Your answer
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!

[hide preview]

Question tools

Follow
1 follower

RSS

Stats

Asked: 2018-02-14 01:37:58 +0800

Seen: 27 times

Last updated: Feb 26