cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <>
Subject Original request attributes in internal block servlet call
Date Tue, 21 Nov 2006 15:35:35 GMT
Currently internal BlockServlet calls do not contain the original 
request parameters or attributes, i.e. the BlockCallHttpServletRequest 
has none of them and no reference to the original request (when called 
from a BlockSource, but this is currently the only scenario anyway).

We are using the request attributes to store the name of the logged-in 
user, because the authentication is done by a servlet filter (which sits 
before the DispatcherServlet). Now when you make an internal call to 
another block this username request attribute gets lost which is bad, 
because you are forced to put all user-related functionality (eg. 
authorisation) in the front-end block sitemap, which is often not possible.

There is also no possibility to make pipelines only available to other 
blocks in the same cocoon webapp, but not for external HTTP requests, 
like you can define an internal-only="true" for pipelines inside a 
sitemap. That would be at least a workaround for having working 

My idea would be to include the original request in the 
BlockCallHttpServletRequest, either by referencing it, or by completely 
including all request params and attributes of the original request.

Technically this could be implemented by storing the original 
HttpRequest in the BlockCallStack (in a ThreadLocalStorage, one request 
per thread) and then provide a static method 
BlockCallStack.getOriginalRequest() that returns that request object, 
which can be called inside BlockConnection where the 
BlockCallHttpServletRequest is created. That one should hold a reference 
and include the params and attributes.

The main question is: is it feasible to always include all request 
parameters and attributes and other information (HTTP method, original 
URI...) or do you sometimes want a "clean" call to another BlockServlet? 
That could be made configurable for the Block sources by having two 
schemes, eg. "block:" and "block-with-params:" (well, that should have a 
better name ;-)

Hey, and if you finally got to this point, thanks for reading all that 


Alexander Klimetschek

View raw message