"Nicola Ken Barozzi" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> The only thing I have "against" this is to start thinking about making
>> "WEB-INF" an optional feature (all throughout the code)... It should be a
>> configurable feature.
>>
>> The "web application" concept collides with a "full-server" concept...
>> Web-Applications were designed to allow multiple web-applications in the
>> same container...
>>
>> With blocks, web applications are "redundant" (not to say, obsolete). Sooo,
>> let's try to think about a possible non-web-application layout...
>
> Suggestions?
>
> The fact is that cocoon.xconf was moved to WEB-INF for security reasons.
> In that servlet environment I would surely move the blocks under
> WEB-INF. IMHO it's simple enough to imagine that in all other
> environments we have a COCOON-INF dir that mimics the WEB_INF one.
Somehow, well, yes, but at the same time, no... WEB-INF is (IMO) a hack,
done for web-applications to be self-contained. If the servlet spec instead
of defining this layout:
$(WEBAPP_ROOT} <- all content goes here
${WEBAPP_ROOT}/WEB-INF <- this is supposed to be "protected"
${WEBAPP_ROOT}/WEB-INF/web.xml <- the configuration file
$(WEBAPP_ROOT}/WEB-INF/classes <- free-range classes
$(WEBAPP_ROOT}/WEB-INF/lib <- libraries
Relied on a "different" (and IMO, more sensitive) layout like:
$(WEBAPP_ROOT} <- this _is_ protected, as...
${WEBAPP_ROOT}/content <- this is where you put all content
${WEBAPP_ROOT}/web.xml <- the configuration file
$(WEBAPP_ROOT}/classes <- free-range classes
$(WEBAPP_ROOT}/lib <- libraries
You'd see how things would change dramatically from the security point of
view: the "default servlet" wouldn't have to do the usual "trick" of
if (getRequestURI().startsWith("/WEB-INF/")) then send a 404...
But simply, to serve files, it would do "getResourceAsStream("content"+...)
therefore enhancing security...
And then operating system you go, file-system you find (I can't tell you how
many problems there _always_ are when you have to see if WEB-INF is
upper/lower-case, what does the filesystem support? If someone on Windows
called its "WEB-INF" "Web-Inf", should that be protected?
IT IS A MESS :-) Basically every servlet which relies on getResource...()
literally has to protect itself from a possible WEB-INF attack... If you
reverse the problem, you just have to add "content" at the beginning of your
served resource, and you're done :-) :-)
Ok, enough ranting about why WEB-INF (IMO) is the wrong hack, now, getting
back to Cocoon, in the webapp's WEB-INF directory I see:
- cocoon.xconf/logkit.xconf/instrumentation.xconf
Ok, it's sensible to have them here, as you never know what servlet
container you have under your butt, and therefore, you might end up with
someone serving you the files ANYHOW... In WEB-INF it should be allright.
My vision? Those are configuration files, so, it might be sensible to have
them completely outside from the web-application directory, see my last
patch to CocoonServlet that enables you to specify a full-filesystem path
for it: first "getResource()" is tried with the WEB-INF path in front of it
(in case we're using Cocoon as a web-application), then a real filesystem
call is done (cool if I want to keep jetty.xml and cocoon.xconf in the same
directory).
- web.xml/classes/lib
Those are "specific" for a web application: web.xml configures the webapp
itself, and in case of -for example- Jetty with direct-servlet-mapping, we
don't need it. Classes and Lib should be used only by the classloader, but
oh, well, we also need them to compile Java Code, as so far, no Java
compiler relies on its classloader, but rather on files (Doesn't Pizza does
that????). IMO, if we provide a "classpath" entry to our compilation
framework, we should make those two directories configurable somehow.
- db/deli/entities/logs
Those are "Cocoon" specific, so they should be made configurable again (why
keeping those in there???)
Of course all those paths should default to lookups using
"getResource("/WEB-INF/...")" (maybe even keeping WEB-INF configurable
somehow?) and then, if not found doing a file-system search using
properties, or another getResource-like call.
That, IMO, will help us not only when Cocoon is used in servlet-only based
containers (such as Jetty), where we can really do some beautiful nasty
tricks if we could have a little bit of control (nasty in the term that
noone thought about them before, more security first of all)
So far, "WEB-INF" is hardcoded into those files:
- src/blocks:
hsqldb/java/org/apache/cocoon/components/hsqldb/ServerImpl.java
- src/java:
org/apache/cocoon/components/language/generator/ProgramGeneratorImpl.java
org/apache/cocoon/components/resolver/ResolverImpl.java
org/apache/cocoon/components/treeprocessor/sitemap/PipelineNode.java
org/apache/cocoon/environment/http/HttpContext.java
org/apache/cocoon/Main.java
org/apache/cocoon/servlet/BootstrapServlet.java
org/apache/cocoon/servlet/CocoonServlet.java
org/apache/cocoon/servlet/ParanoidCocoonServlet.java
- src/scratchpad
src/org/apache/cocoon/ant/CocoonTask.java
src/org/apache/cocoon/components/axis/SoapServerImpl.java
src/org/apache/cocoon/components/repository/impl/SlideRepository.java
And another bunch of non-java files... (XMLs, XSLs mainly):
./src/blocks/fop/conf/fop.xmap
./src/blocks/linkrewriter/samples/sitedemo/README.txt
./src/documentation/cocoon.xconf
./src/documentation/xdocs/ctwig/ctwig-basic03.xml
./src/documentation/xdocs/developing/deli.xml
./src/documentation/xdocs/developing/httprequest.xml
./src/documentation/xdocs/dtd/README
./src/documentation/xdocs/faq/faq-configure-c2.xml
./src/documentation/xdocs/faq/faq-databases.xml
./src/documentation/xdocs/faq/faq-install.xml
./src/documentation/xdocs/howto/howto-flow-debugger.xml
./src/documentation/xdocs/howto/howto-html-pdf-publishing.xml
./src/documentation/xdocs/howto/howto-paginator-transformer.xml
./src/documentation/xdocs/installing/index.xml
./src/documentation/xdocs/plan/catalog.xml
./src/documentation/xdocs/tutorial/tutorial-develop-webapp.xml
./src/documentation/xdocs/tutorial/tutorial-generator.xml
./src/documentation/xdocs/tutorial/tutorial-rmi-generator.xml
./src/documentation/xdocs/userdocs/concepts/catalog.xml
./src/documentation/xdocs/userdocs/concepts/index.xml
./src/documentation/xdocs/userdocs/concepts/validation.xml
./src/documentation/xdocs/userdocs/generators/jsp-generator.xml
./src/java/org/apache/cocoon/components/flow/flow.xconf
./src/java/org/apache/cocoon/components/resolver/resolver.xconf
./src/resources/dev/emacs/prj.el.in
./src/scratchpad/schecoon/ChangeLog
./src/scratchpad/src/org/apache/cocoon/ant/readme.txt
./src/scratchpad/webapp/samples/slide/README
./src/scratchpad/webapp/samples/slide/web.xml
./src/test/CatalogManager.properties
./src/webapp/cocoon.xconf.moved
./src/webapp/samples/common/style/xsl/html/error2html.xsl
./src/webapp/samples/docs/samples/sample-dynamic.xml
./src/webapp/samples/flow/docs/book.xml
./src/webapp/samples/flow/docs/continuations.xml
./src/webapp/samples/flow/docs/how-does-it-work.xml
./src/webapp/samples/flow/docs/index.xml
./src/webapp/samples/flow/docs/invalidContinuation.xml
./src/webapp/samples/flow/docs/samples.xml
./src/webapp/samples/stylesheets/system/error2html.xsl
./src/webapp/WEB-INF/classes/CatalogManager.properties
./src/webapp/WEB-INF/cocoon.xconf
./src/webapp/WEB-INF/deli/config/deliConfig.xml
./src/webapp/WEB-INF/deli/config/legacyDevice.xml
./src/webapp/WEB-INF/logkit.xconf
./src/webapp/WEB-INF/web.xml
>>> issues
>>> ---------
>>>
>>> Small step, but already there are issues.
>>>
>>> 1. when we will enable versioning, we can have that a block uses
>>> a version of some libraries, and others another.
>>> This mean that we have to load the blocks with different
>>> classloaders, right?
>>
>> Correct... And each classloader should work in the "web-application" mode:
>> check _HERE_ first, and _THEN_ go to the parent classloader... It's not a
>> big issue though, it could be a problem if we want to start "live reloading"
>> of blocks, or pass instances of the same class around between different
>> blocks...
>
> yup, let's KISS for now.
Hm... I was actually thinking whether we wanted it or not last night... I'm
thinking, I don't know if cocoon-blocks should be allowed to "rely" on a
particular version of a given library... If two blocks use the same lib,
they should be using the same version, and both should be using the latest
version... I don't know. If needed, anyohow, I can throw in a ClassLoader
implementation (I use it for a thing called "OracleObjects" here at VNU and
it does more or less what you need)...
Pier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
