Obviously, if my application doesn't use any uploads I should disable them in web.xml. But right now, it's all or nothing: I either allow all users to upload _on any page_ (if they create a form that posts to any url in cocoon's space), or I totally disallow uploads. I've been thinking through enabling configs for resource-based, or even authentication-based restrictions for uploads. What would others think?
I've been thinking about this for a while and I thought about waiting for 2.1 before sending these RT, but I just wanted to introduce them briefly before a quick-hack solution is implemented.
In my continuous quest to see if our pipeline architecture is enough for even the most complex web needs, I found out that it is not always the case.
After we release 2.1, I will introduce a discussion about "pipeline aspects" in order to suggest a more elegant approach to:
- handling webdav - handling uploading - handling views - handling proxying - handling chunked encoding
In short, all those behaviors that require deep contact with the internals of the HTTP stream both in reading and writing and, potentialy, from all the pipeline components.
The way we designed the pipelines was mediated out of the servlet API and the servlet API was designed exactly to prevent you from having to know (or manage) the HTTP internals.
Since the approach was a very useful one (in short, clean IoC applied to the HTTP paradigm), we designed the environment in that direction.
But we have one major difference between the servlet API: the API is designed so that one or more web resource is associated to one (or, using request dispaching, a procedural chain of) programmatic request handlers (the servlets or the jsp pages).
Our model is entirely different and it's pretty rare (see readers) that we have only one request-handling component that touches the request.
Cocoon aims at complete and clean SoC and started for publishing needs (stateless, GET-driven). We achieved that with the sitemap. Then we moved into webapps (stateful, GET/POST roundtrip driven). I think we solved all possible issues with the flow.
The question I posed to myself was: now that we have both pipelines, sitemaps and flows, are we able to handle the complexity of WebDAV in a clean way?
The answer is, unfortunately, "no".
Don't get me wrong: you can write a cocoon-enabled webdav-app (webdav-apps are webapps that use not only GET/POST but all the webdav extension to the HTTP protocol!) even with 2.1 but it won't be so clean.
why?
well, unlike GET/POST actions which inherently assume a resource-oriented granularity, there are other actions (and I consider the cocoon view a special case of HTTP content negotiation) that require 'cross cutting' behavior across different resources.
I think the sitemap semantics is inherently great at describing concerns that can be well separated (using matching, for example) but very poor at describing crosscutting concerns.
Examples of crosscutting concerns are:
1) webdav enabled 2) restricted/protected 3) proxiable 4) viewable 5) upload handling 6) pipeline-wide global parameters
There is no single mechanism to handle all those.
Views have a special semantics. Upload handling is made *explicitly* cross-cut across the entire domain space (and this is, rightly, a potential vulnerable point, expecially if associated with resource restriction).
The best example of crosscutting concern is Restriction/protection: this is most elegantly done (currently) with wrapping a map:mount.
I wonder is this is, architecturally, the best approach.
In theory, it should be possible to define 'behavior modifiers' that wrap pipelines and transparently provide different behaviors to them.
I see two possible approaches:
- external modification - internal modification
external modification is done with wrapping a mount, like we do today for restricting access to an entire sub-sitemap.
internal modification is done for views, but this required a special semantics added to the sitemap and, in retrospect, it seems to me that it was a mistake.
We can't use Actions or flow to modify pipeline behaviors unless we give full access to the underlying object model, opening the gates for abuses.
We can't add the possibility for people to add their own sitemap semantics, or we have the same abuse problem.
I see two possible solutions, depending on where we want to go:
1) create a 'wrapping' component
or
2) add the ability to add pluggable <map:pipeline> metadata without exposing hooks for internal pipeline abuses.
Note that these are very random thoughts and I don't have a coherent view of what we need and how we solve those issue. at the same time, I think it's worth thinking at those pipeline-wide problems with little aspect orientation in mind.
Stefano.
