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
