Geoff Howard wrote:
<snip/>By the way, I think there are bigger security problems in cocoon...
Also, is cocoon-reload still enabled by default? seems a wget in a loop with ?cocoon-reload=true could put a site in a world of hurt... (by the way, last time I checked Jetty/Cocoon cvs is barfing on that..)
With jetty, try http://localhost:8888?cocoon-reload=true - without '/' symbol. Jetty is ... different ... from other engines.
I've worked on the multipart file uploads because I felt the original status posed security/abuse issues. It's now at a better point but I think there are still some issues I'm not (at an RF level) convinced are OK. IIRC the default is now to allow "in-memory" uploads only which is a step better.
Is it? With in-memory upload you can get to OutOfMemory exceptions and potentially corrupt cocoon instance. With file uploads, you can create 100Mb file systems which you can fill up but you won't disturb functionality of the server. I don't see how in-memory uploads are more secure; I see them as *less* secure.
Well, in combination with the max-upload-size parameter (or whatever it's called) I felt that better. If I can cause the request to ignore multipart files bigger than xMB, that seems to mitigate the risk. But that's worth some discussion. My worry with autosaving all files is 1) I can purposely fill up your hard drive, given time. 2) Could a user more clever than I create a POST request that would cause a file to be placed somewhere other than the upload dir?
And, of course, best approach is no uploads at all :)
Well, you were probably half kidding/half serious. 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?
Geoff
