cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Where did ProducerFromRequest go?
Date Fri, 25 Aug 2000 13:04:35 GMT
Nadine Carlton wrote:
> Thanks for the replies.
> I do have a Cocoon app running using the request.getParameter
> to use data from the Java server over HTTP POST.  (I will read on the
> xspParser object though, Robin, for when I have more data to pass.)
> However, I also agree with Uli that there are some servers that will
> remain Java and some that will use Cocoon and I do need to access
> services on multiple machines.  I'm trying to understand the advantages
> and disadvantages of making that intermediate Java server also a
> Cocoon server.  I'm not sure how to have Cocoon invoke another
> Cocoon app.  Can it?

Sure it can: thru normal HTTP. We should definately include a
URLProducer in the disto, anyone wants to volunteer for that?

C'mon, it's piece of cake.
> My intermediate java server currently has code to transform XML
> from multiple backend Cocoon server responses into one XML
> before returning to the client.  I need to apply some transforms
> that I will be writing in XSL at that intermediate layer too.  It would
> be nice to do this with Cocoon, but this is where I have the question
> about 3 tier and Cocoon calling Cocoon versus Java calling Cocoon.

Well, that's up to the things you have to do.

> How would I apply multiple stylesheets to merge, transform and
> then format the XML result for presentation?  Currently the intermediate
> server uses the processor.process(XSLTInputSource,XSLTInputSource,
> XSLTResultTarget) method in Xalan.
> Anyway, I need to be able to explain
> the design choice to the "write everything in Java we can for simpler
> servers"
> camp versus the "use all Cocoon for consistency" camp here.  And to myself
> of course. :-)

I don't think I can help you here.
> ProducerfromRequest sounded similar enough that I wanted to ask about
> it.  By the way, I tried to search the mail archive to find out about the
> security issue since I assume it was already discussed.  

The security hole is pretty nasty: you can pass using POST an XSP page
that can get compiled, executed and, thus, allows people to execute your
own code (normally nasty) with the security priviledged of the JVM
that's running Cocoon.

Opss :(

So, disable your ProducerFromRequest if you haven't done.

Robin discovered this and told us months ago (and we informed our main
users privately not to generate panic), we could patch
ProducerFromRequest to strip out <?cocoon-process type="xsp"?> but I
wanted to blast it because it was a pretty bad hack since day one and I
took the chance to ask to remove it.

No, we haven't discussed this in details, this is the first time and I
wanted to wait for Cocoon 1.8 to come out, but the fix is pretty simple
so you can do it yourself: just remove ProducerFromRequest from your file.

> The search for keyword
> "ProducerfromRequest" found no matches and "security" returned 197 matches
> that aren't labelled for easy identification of something like the thread
> subject.  Sigh.  I really feel like a newbie when I can't get the search
> engine
> to work, but any suggestions for a keyword would be great.  Or can
> someone mention the functionality and security issue of ProducerfromRequest
> again?  I'd like to avoid any known security holes if I can.

The security issues is the usual one: don't let users influence the
logic of your web application without controlling it.

In Cocoon1, this means stip out any processing instructions from POST.

In Cocoon2, the sitemap design removes the problem alltogether.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message