[VOLUNTEER] Re: DO NOT REPLY [Bug 13541] New: - SAVE_UPLOAD_FILES_TO_DISK should be configurable

[Geoff Howard <co...@yahoo.com>]

I'm willing to volunteer to work on issues surrounding
this "bug" if someone can get me up to speed on where
things stand in the code.  Specifically, what would
help for starters is: 
1) Why is SAVE_UPLOADED_FILES_TO_DISK hardcoded now? 
I assume that its because of some unresolved problem
with the condition in MultipartParser.java which
handles the false condition?  Is something wrong with
FilePartArray as it stands now?  Is this not the
correct solution?
2) What is the story with
MaybeUploadRequestFactoryImpl?  From the comments in
the code it seems unfinished.
3) Same with SimpleRequestFactoryImpl?  It seems like
specifying one of these in web.xml is overlapped in
functionality with SAVE_UPLOADED_FILES_TO_DISK.  If
so, which direction should it go?  To them or away
from them?
4) There is a message in the archives demonstrating
the use of an action to deal with uploads (though I
think it depends on the default functionality).  Is
this the right direction to encourage use?  I assume
that InputModules could handle things the same way if
they replace Actions in the future.

It seems to me that this is what is needed for
starters:
- files should not be uploaded and saved by default
from any page.  that has security hole written all
over it.
- when upload of a file is desired, there should be a
configurable default directory (as there is now) _and_
the ability to designate alternative locations either
in the sitemap, and _maybe_ via runtime/request
parameters.
- ideally, some pipelines should be able to allow them
and others not - this way you can require
authentication easily.  any other suggestions on how
to allow uploads only to select users?

The first could be handled simply by changing
CocoonServlet to use a parameter from web.xml instead
of it's final boolean.  (I'd also argue that if the
other changes don't happen, this parameter should be
set to false in the default config for security
reasons).

The second would involve modifying the behavior of
MultipartParser and friends in
org.apache.cocoon.matching.* 

Am I wrong that the default configuration means that I
can upload files all day long to live cocoon instances
everywhere right now (unless they have specified
SimpleRequestFactoryImpl in web.xml)?!?

Geoff Howard

--- bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE
> AT
>
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13541>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED
> AND 
> INSERTED IN THE BUG DATABASE.
> 
>
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13541
> 
> SAVE_UPLOAD_FILES_TO_DISK should be configurable
> 
>            Summary: SAVE_UPLOAD_FILES_TO_DISK should
> be configurable
>            Product: Cocoon 2
>            Version: Current CVS
>           Platform: All
>         OS/Version: All
>             Status: NEW
>           Severity: Enhancement
>           Priority: Other
>          Component: core
>         AssignedTo: cocoon-dev@xml.apache.org
>         ReportedBy: Alfred.Nathaniel@swx.com
> 
> 
> CocoonServlet passes a final boolean
> SAVE_UPLOADED_FILES_TO_DISK = true to the 
> RequestFactory.
> 
> This should become a ServetConfig init parameter to
> allow using the 
> MultipartRequestFactoryImpl producing FilePartArray
> objects for upload requests.
> 
> Provided one is not afraid of memory exhaustion,
> FilePartArray avoids the 
> problems of FilePartFile (race condition, privacy
> issue, housekeeping).
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email:
> cocoon-dev-help@xml.apache.org
> 


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com

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

Re: [VOLUNTEER] Re: DO NOT REPLY [Bug 13541] New: - SAVE_UPLOAD_FILES_TO_DISK should be configurable

[Bernhard Huber <be...@a1.net>]

hi,
don't know much about the upload internals, just some hints about the
directory handling

>It seems to me that this is what is needed for
>starters:
>- files should not be uploaded and saved by default
>from any page.  that has security hole written all
>over it.
>- when upload of a file is desired, there should be a
>configurable default directory (as there is now) _and_
>the ability to designate alternative locations either
>in the sitemap, and _maybe_ via runtime/request
>parameters.
>
As a short hint, i remember that servlet-spec is quit restrictive about 
temporary
files there is a servlet config parameter, snippet from the servlet spec 2.2
--start--
It is often useful for Application Developers to have a temporary 
working area on the local
filesystem. All servlet containers must provide a private temporary 
directory per servlet context and
make it available via the context attribute of 
javax.servlet.context.tempdir. The
object associated with the attribute must be of type java.io.File.
--end--

Moreover the file should take the servlet session into account if it is 
available, as
more than one user may upload files.

bye bernhard



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