programatic creation of objects

Thursday 07 July 2005 1:28:19 pm

ezPublish has some very powerful ways of managing objects stored in the database and displaying their attributes. However the only way to create these objects, in the out-of-the-box version of ezPublish, is via a two-stage html form based process. The data that is to become the object is entered into the form by the user. There are some ways to add additional data using hidden form fields (see http://ez.no/community/contribs/hacks/object_creator#msg78747 and http://ez.no/community/forum/setup_design/how_to_use_hidden_form_fields_to_specify_values_of_attributes ) and there is a hack to collapse the two-stage process into one: http://ez.no/community/contribs/hacks/one_click_new_object_and_publish_preview_hack. However there is a huge security weakness in the exposure of the attribute values in the html code for the form. The user can view the "hidden" values by looking at the html code and the hacker can substitute different values thus generating an object you may not want.

I cannot understand why ezPublish doesn't come with a template function for generating objects and populating their attributes on the fly. It is as if the predefined use of ezPublish is restricted to the creation of objects using html forms. If we could create objects programatically, the e-commerce uses of ezPublish would be greatly expanded.

My suggestion is that a template function for the generation of objects on-the-fly is provided. It would have parameters for the class-type, the owner, the attribute values, the location etc.. Because it is template code, exposure of the parameter values to the user would be eliminated and several rather precarious hacks for achieving this in insecure and round-about ways (including mine) would become obsolete.

Thursday 07 July 2005 2:03:25 pm

The template is run when a user invokes it by visiting a particular part of the site.

I accept that there are issues to do with caching but are there not ways to control the caching?

I feel that the inclusion of a facility for programatically creating objects would be so valuable that a resolution to these issues should be sought.

I think a useful thought experiment is to compare the programatic creation of objects with the manual, form-based, process. Imagine instead the various field filling in and button clicks to be done programatically instead.

Friday 08 July 2005 2:57:25 am

Bruce,

Yes, certainly the roles/policies system in ezP is powerful. But it cannot stop a hacker substituting his/her own values into a form for the creation of an object. If the object consists of commercially sensitive data (and some of the attributes are supposedly fixed and determined programatically) I see a huge security weakenss.

Given that the use of html forms is the only way we have to create objects and that this mechanism is inherently insecure, I wonder if an alternative method for object creation should be provided.

I am aware of the caching issues but do not fully understand the caching mechanism and would like some advice about how these problems could be surmounted. It should surely be possible, given the gereral purpose, expandable, e-commerce intent of ezP.

Tuesday 12 July 2005 1:41:49 am

Bruce,

you say

I take it that you are referring to the way that the attributes utilise hidden fields and the naming of variables in edit screens?

I'm relatively convinced that the methods that ez employs do not enable the substitution of these values in a way that would allow for the modification of information that the user would not normally have access to.

I'm not sure we're talking about quite the same thing, so I shall elaborate.

In my application a logged in user needs to create objects on the fly for an e-commerce application.

The only way to do this (please correct me if I am wrong) is through the use of a form.

Some of the attribute values of the new object can be determined programatically and submitted via the form (using hidden fields) to the object creation mechanism.

My problem with security is that these "hidden" fields can be viewed using the view source facility of the browser. A user could create his own web form and, using this knowledge, submit bogus values for these attribute values. At the very least he can see the values of hidden attributes that I would rather he didn't.

Seeing this from a more distanct perspective, ezP seems like a programming system that is very powerful in many ways but without the facility for creating new variables or changing them without saying to the world "here are the variables I am going to create, you can step in here and change their values if you wish". This is only because we cannot create objects directly in template code. We are forced to use a form.

Please tell me I am wrong.

Tuesday 12 July 2005 3:14:02 am

Thanks Bruce,

The only mod needed to insert an extra hidden field is something like

<input type="hidden" 
       name="{$attribute_base}_ezstring_data_text_{$content_attributes[2].id}"
       value="the new value for extrafield" />

as described in http://ez.no/community/forum/setup_design/how_to_use_hidden_form_fields_to_specify_values_of_attributes

But what else am I to do if I want to hold non-transient data determined by the user?

Yes, I could censor the final publishing of the object via a workflow but the time delay of the workflow is unacceptable.

To summarise, if we want non-transient user-related data we have to create an object. To create an object on-the-fly we need to use a form. The form exposes the values and action destination to the user and possibly also allows the hacker to alter these values.

Any alternative ideas gratefully received.

Tuesday 12 July 2005 4:14:18 am

Bruce,

I started to reply to your points but realised this was rather more than I wanted to say in a public forum.

Could you email me on nigeldodd [AT] blueyonder [dot] co [dot] uk