Office Connector ignores result of authentication, calls its own authenticator

The editinword servlet calls its own authenticator even after Seraph's SecurityFilter has logged in the user.

Even if there is a need for re-authenticating a request(such as to secure the WebDAV-enabled save target that Word is given...?), there is never any valid reason to use different code to do it.

Assuming that the choice to authenticate a request after the SecurityFilter has already done so is not a design flaw, I still note two problems, both of which come into play in producing the presenting symptoms:

1. Despite the authenticated user being present in both the session and the ThreadLocal User object, the plugin does not find them when it does its authorization check, which will then fail if anonymous updates are forbidden (I suspect that this is the reason the plugin has a configuration option to require authentication).
2. If an authenticated user is not found (which will always be the case, apparently) and the above-mentioned option is true (its default value), com.benryan.servlet.webdav.ZenWebDavServlet.authenticate() is called. I haven't learned exactly how it does its job, but have observed two things: first, that it does not call the Seraph-configured authenticator; second, that it goes to the Authorization header for the credentials. The second is probably innocuous, since Word is only able to use HTTP Basic authentication, but the first is unquestionably wrong.

Of course, if the default authenticator is used, this will not be a problem; it will simply validate the same credentials against the same sources, ergo with the same result. If, however, a custom authenticator is used that does not behave exactly like the default one, the result is that successfully authenticated and duly authorized requests are nevertheless refused by the plugin.

The custom authenticator would thus appear to be the culprit. However, I can tell you with certainty that it is not; what I describe above also occurs with the default authenticator, though it takes a debugger to confirm it.

My considered opinion is that the root of the problem is the plugin's inability to retrieve the user from either the AuthenticationContext or the session attribute where SecurityFilter stores it. If there's any way you can suggest to repair or bypass that problem, it would be wonderful. I've been fighting this problem for over a year now and am very frustrated.