Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 33345 invoked from network); 27 Oct 2003 20:36:51 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 27 Oct 2003 20:36:51 -0000 Received: (qmail 99044 invoked by uid 500); 27 Oct 2003 20:36:35 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 99012 invoked by uid 500); 27 Oct 2003 20:36:34 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 98985 invoked from network); 27 Oct 2003 20:36:34 -0000 Received: from unknown (HELO pulse.betaversion.org) (217.158.110.65) by daedalus.apache.org with SMTP; 27 Oct 2003 20:36:34 -0000 Received: (qmail 13631 invoked from network); 27 Oct 2003 20:36:37 -0000 Received: from unknown (HELO apache.org) (stefano@80.105.91.155) by pulse.betaversion.org with SMTP; 27 Oct 2003 20:36:37 -0000 Date: Mon, 27 Oct 2003 21:36:46 +0100 Subject: Re: [proposal] Doco Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "'James Developers List'" , , To: dev@cocoon.apache.org From: Stefano Mazzocchi In-Reply-To: <200310271436.h9REaLb30066@server1.livestoryboard.com> Message-Id: <487895B2-08BD-11D8-871A-000393D2CB02@apache.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N On Monday, Oct 27, 2003, at 15:35 Europe/Rome, Robert Koberg wrote: >> nah, dude, look: doco has a very precise editing access point. You can >> *ONLY* modify xml content. So, changes to .htaccess, CGI scripts, >> servlet upload, sql injection, cross-site-scripting, and you next >> favorite attack will NOT work because the system prevents it by design >> [not saying it cannot happen, but if it does it's a bug, not a faulty >> design] > > FWIW, I agree. Perhaps the submit goes to a well-formedness check (or > even > better?, schema/dtd validation). If it fails, it doesn't even enter the > approval process. Absolutely. This wasn't mentioned, but planned. I will do relaxng validation before allowing any xml data into the system. This should be enough for documentation. > Perhaps a notification email is sent describing that an > invalid submittal was sent. Nah, it would just fail and log the failure. No need to spam further since it might well be a bug in the editing software ;-) [I have experienced a few of them as well] > The user is returned an error page saying the > post was rejected, in case it was just a mistake. > > On another note, can images/PDFs/other-binaries be uploaded? Damn, forgot about this! My suggestion would be to process the binary file and determine if it's an image or not. If not, reject it right away. [there should be *NO* need to upload any other binary file ] -- Stefano.