cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <>
Subject RE: [RT] Towards a new/another Forms Framework
Date Wed, 02 Apr 2003 14:16:33 GMT

Thanks for your comments. What is an example of something dangerous? 

During a preview view, the submitter would not be able to access the file,
but through the CMS tool, which would perform a server-side transformation
on the XML (or fail). How could some dangerous content piece be used in this

During an editing view the file is sent to the client from a request to
simply return the file. How would this be potentially dangerous?

The file is in no way accessible from the outside. It is only accessible
through the tool by an authorized member of a group. The group lives in a
chroot jail.

Sorry if I am showing some basic naivete!


> -----Original Message-----
> From: Geissel, Adrian []
> Sent: Wednesday, April 02, 2003 5:51 AM

> Hi,
> I've been watching this thread for a while now, and as a regular Cocoon
> power-user, I am keen to see a good forms framework. Rob's comments have
> prompted an important consideration for such a framework.
> Where client-side validation is used, it *must* be matched but a second-
> pass
> server side. This is fundamental to security (also on another thread) -
> otherwise anyone can hack a HTML form to submit potentially dangerous
> content to the server. JavaScript (or similar) should be seen as a
> usability
> enhancement, not as the defacto solution.
> One other [R]Thought regarding a X??Form framework is that data-form-
> layout
> separation needs to be considered. I am concerned with the way that XForms
> is integrated into the HTML - relatively poor SoC :( But thankfully
> nothing
> a good stylesheet can't cure!
> /Adrian
> -----Original Message-----
> From: Robert Koberg []
> Sent: Wednesday 02 April 2003 15:27
> Hi,
> > -----Original Message-----
> > From: Stefano Mazzocchi []
> > Sent: Wednesday, April 02, 2003 3:25 AM
> > To:
> > But I also want to point out something that I'll need a lot in the
> > future: the XML datatype in a form.
> >
> > I would like to be able to submit an entire XML island into a form
> > textarea and have the server-side form handler be able to validate it
> > against a particular schema.
> But that would be invalid markup. It would be better to use a PUT (I am
> still using a POST with a hidden INPUT...). We do the XML Schema
> validation
> client-side and just send the updated XML back to the server for storage.
> >
> > That would be *KILLER* for serious content management solutions where
> > all the data aggregation from the document can be done via javascript on
> > the client side directly (and it's pretty dead easy also to make
> > transparently portable for 6th generation browsers!).
> I am confused. In the previous paragraph you say you want to submit it to
> the server for validation. But in the above para you talk about client-
> side
> validation?
> Why not use some schema dialect (XML Schema seems to have achieved
> critical
> mass???) and add a form namespace that indicates the widgets. You get
> datatyping for free.
> ?
> -Rob

View raw message