|
The Amdatu Web dispatcher is responsible for handling (almost) all (tenant aware) http requests into the framework. It does so by intercepting requests in the standard HttpService chain into a dynamic/customized chain.
If no match is found in the latter the request is delegated back to the former. This fallback allows support of 3rd party component such as webconsole that register directly (non whiteboard) with the HttpService.
This works but there are functional limitations such as AMDATU-425, where a default servlet in the custom chain will prevent any access to the standard chain. Furthermore, we can not easily intercept and control component that register directly with the HttpService. Basically, there are two paths and one of those is outside the Amdatu Web control.
Unifying this into one point of control will allow us to resolve this altogether. Possible attack vectors are:
1) Possibly add dynamic/filter based chains to Apache Felix Http service/whiteboard like we did with autoconf? This would nice, but together with HttpContext management this may prove rather difficult. Also because it is beyond the spec this will lock us into the Apache Felix implementation.
2) Internalizing HttpService into Dispatcher. In fact HttpService is not doing much more then delegating to Dispatcher. Internalizing the code brings it under our full control allowing us to handle non-whiteboard scenarios much easier.
3) Intercepting calls to HttpService using aspects and redirecting to Dispatcher. Same as 2 except for the fact that the HttpService needs separate provisioning and can, in theory, be any implementation.
At the time of writing this I feel option 2 may be best as it will not only give us full control over the functional aspect but the implementation as well. For one of the most performance critical parts this may not be a bad idea.
[0] http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Web
[1] http://jira.amdatu.org/jira/browse/AMDATU-425
|
