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 --- [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > 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: > [EMAIL PROTECTED] > For additional commands, email: > [EMAIL PROTECTED] > __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
