cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Wyles <...@robinwyles.com>
Subject Re: Servlet protocol and internal pipelines
Date Fri, 21 Nov 2008 10:08:49 GMT
Hi Grzegorz,

On 20 Nov 2008, at 23:21, Grzegorz Kossakowski wrote:

> Robin Wyles pisze:
>> Hi,
>>
>> Apologies for posting on the dev list, but I've been asking this  
>> for a
>> while on users and am still searching for an answer (I'm kind of
>> desperate now!)....
>
> Sorry for not responding on users mailing list. I've been offline  
> for some time and didn't have a
> touch with a project.
>
>> In the default sitemap generated with the block archetype there is a
>> pipeline as follows:
>>
>> <map:pipeline id="internal-resource" internal-only="true">
>>       <!-- Put matchers for internal (accessible only to Cocoon  
>> blocks)
>> resources here
>>         More details:
>> http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1345.html -->
>>       <map:match pattern="resource/internal/**">
>>         <map:read src="resource/internal/{1}"/>
>>       </map:match>
>>  </map:pipeline>
>>
>> On the docs page linked to above it states that blocks may have
>> "internal resources that are accessible to other block via servlet:
>> protocol". However, from my tests it seems that internal-only  
>> pipelines
>> are still not accessible via the servlet protocol. So, out of the box
>> any matchers placed in the above pipeline result in a
>> SourceNotFoundException when accessed via the servlet protocol.
>>
>> Can any devs please confirm whether:
>>
>> 1. Internal pipelines *should* be accessible via the servlet  
>> protocol.
>
> Yes, it should be.

Phew :-)

>
>> 2. Internal pipelines *are* accessible via the servlet protocol.
>
> No they aren't.

Boo :-(

>
>> If 1 is true and 2 is false then I'm very surprised that this hasn't
>> been bought up before on the user list as it seems to contradict the
>> documentation and also severely limit the usefulness of the servlet
>> protocol - I can't believe we're supposed to leave our SSF only
>> pipelines accessible to the world at large! I have a test block here
>> that demonstrates the issue if anyone is interested...
>
> Actually, I've been aware of this problem for a long time but never  
> got myself to fix it, which is a
> shame, of course.
>
> The thing is about SSF's design, it's really designed such a way  
> that request coming from SSF looks
> very the same way as it was coming from an external client (like  
> browser). That's been done on
> purpose in order to avoid any hidden dependencies between SSF and  
> Cocoon's core.
>
> As a consequence of this design, there is no way how sitemap  
> processor can allow requests coming
> from SSF to access internal-only pipelines.
>
> When it comes to documentation, it was written before the actual  
> implementation was made and later
> on the whole issue has been forgotten.
>
> I don't recall the proposal for implementing this functionality but  
> probably the simplest possible
> approach would be to introduce common contract that both sides (SSF  
> and Cocoon's Core) agree to
> follow but the one that does not introduce any hard dependencies on  
> each other. This leaves
> implementing special interface (indicator) out of consideration.

I had a dig around in the code yesterday and more or less came to the  
same conclusion - very hard to do without spoiling SSF's nice lack of  
dependencies.


> Nevertheless, SSF could still indicate that coming request is  
> performed internally by adding some
> special request attribute. This might be a potential security hole  
> so I would classify such a
> solution a temporary one.

It seems the check on the pipeline type and environment type is done  
by o.a.c.components.treeprocessor.sitemap.PipelineNode, I made a  
simple patch here that checks the request's scheme; if it is  
'servlet' and the pipeline is internal only, then processing is  
allowed to continue. While not ideal, I think this method poses less  
of a security risk than using a special request attribute. Also it's  
only one extra line in one class. WDYT?

>
> I believe implementing such a functionality on both SSF and Sitemap- 
> engine sides would be rather
> easy task and I'm willing to help with preparing the patch and  
> applying it. I would require a valid
> test-case for it before it gets accepted.

Can you give me some hints as to how I can write a unit test for  
this? I'm familiar with writing tests for sitemap components but I'm  
not sure how to set up a test pipeline and set its attributes  
accordingly.

Cheers,

Robin

Mime
View raw message