Hi, You are right - with a few exceptions. ;-)
In many (most?) environments the CMIS server is embedded into a DMS system or an application server or a cloud infrastructure or something similar, which does the authentication check before the request actually reaches the CMIS implementation. For a standalone CMIS server a Servlet filter is the preferred approach. There are many different authentication approaches; standard and proprietary approaches. If you can do the authentication by looking the request HTTP headers or checking a SSL client certificate, you should do that before the request hits OpenCMIS. That is, an unauthenticated request is rejected early and the request body is not read. But there are a few authentication methods and authentication rules that require reading the request body first, because the authentication information is in the body. For example, if the UsernameToken authentication is used in the Web Service binding the user name and password are in the body. A proprietary authentication method might check for a custom parameter that contains an additional secret or an application identifier or something similar. The body cannot be read twice. If you read the body in a filter, you break at least all CMIS calls that accept content. OpenCMIS has to read the body. To allow those authentication methods that require data from the body, OpenCMIS provides multiple places where those checks can be done with full access to the body. In this case you are right. Reading and managing the body consumes resources, which will be lost if the authentication is rejected. OpenCMIS makes sure that a malicious client cannot send an infinite stream of data, but if your resources are smaller than the built-in OpenCMIS limits you are in trouble. In the end it's up to the developers and operators if that is acceptable or not. I wouldn't do it.
- Florian
Whilst working on a CMIS server implementation I happened to be examining the CmisBrowserBindingServlet class and noticed that for HTTP POST requests POSTHttpServletRequestWrapper is instantiated before any authentication checks are carried out (e.g. before getCallContextHandler() is invoked where a TokenHandler can check the request). POSTHttpServletRequestWrapper appears to process multi-part requests as soon as it is created, getting an output stream to store data. Unless I am mistaken (and forgive me if I am), it is conceivable that this approach is vulnerable to Denial of Service attacks: you can send a bunch of POST requests with multi-part data to the server that will cause it to allocate memory (if less than memory threshold) and or temp file space (if greater than memory threshold) and exhaust system resources. I would suggest that authentication should be checked before processing multi-part requests in keeping with best practices (e.g. rejecting unauthenticated requests as soon as possible).
