cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [VOLUNTEER] Re: DO NOT REPLY [Bug 13541] New: - SAVE_UPLOAD_FILES_TO_DISK should be configurable
Date Mon, 14 Oct 2002 16:25:52 GMT


> From: Nathaniel Alfred [mailto:Alfred.Nathaniel@swx.com] 
> 
> But bypassing access controll?
> 
> Do you fancy a upload page nicely protected by SunRise and 
> still everybody can inject fake files by a request I could 
> almost type on the keyboard:
> 
>    POST /index.html HTTP/1.1
>    Content-type: multipart/form-data
>    ...
> 
> From my experience, Open Source products are called bad names in the
> corporate world already for far more theoretical holes.
 
I am aware of that - I have contributed with some names myself, and
here's another one:

    The request processing in Cocoon in a bag of shit.

I intend to patch it into a non-bag-of-shit-state. I share your
concern for the holes that exist - and the solution is to provide
a finer level of granularity for the request factories (currently it
is classloader scoped - anyone running Cocoon as a shared library take
note). Whether that level is pipeline or webapp remains to be seen,
but my first priority is to rework the infrastructure into a shape
where such changes can be made at all.

As I said, the request factory is currently classloader-scoped.

Once that is gone, we have the theoretical possibility of having 
more than one request factory in the whole system, and *then* we can
look into all sorts of security measurements.

/LS


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message