Forums / Suggestions / programatic creation of objects

programatic creation of objects

Author Message

nigel dodd

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.

Frederik Holljen

Thursday 07 July 2005 1:42:12 pm

eZ publish does not have any (stored) data altering functions to use from the template language. The reason for this is simple: because of caching you can not know when your template is actually run. If you have data altering functions in your template the result would be more or less random unless you turn of caching.

nigel dodd

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.

Bruce Morrison

Thursday 07 July 2005 4:17:37 pm

Hi Nigel

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.

Sure it's the case that the hidden values may be changed but eZ will not generate objects that the current user does not have permissions to.

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

nigel dodd

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.

Bruce Morrison

Monday 11 July 2005 6:29:45 pm

Hi Nigel

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.

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.

Is this something they you have been able to do or just speculation? If you are correct it would be a massive security issue.

I wonder if an alternative method for object
creation should be provided.

While it is not a packaged feature of the system, it is certainly possible. I believe there are some examples of import scripts in the Contribs area.

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

nigel dodd

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.

Bruce Morrison

Tuesday 12 July 2005 2:44:54 am

Hi Nigel

I think was are pretty much on the same track. It sounds like you have modified the edit template of a specific class to alow you to store values in certain attributes via hidden fom fields, based on the input of others?

If this is the case then this _method_ will open the system up to the possibility of "hackers" injecting bogus values into these attributes. This is not an eZ publish issue but and isue with how you are using the system to achieve your goal.

To bypass this issue you would need to introduce a workflow event that occurs before publishing that sets the required attribute values accordingly.

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

nigel dodd

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.

Bruce Morrison

Tuesday 12 July 2005 3:47:03 am

Hi Nigel

I'm not clear on the context of what you are tring to do. I do know that by using this method you do indeed open yourself up to the issues you described.

If you explain what you are tring to do, not how I may be in a better position to offer advice.

By "non-transient data" do you mean data that does not change?

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

Do you mean the time it would take for the workflow to occur or develop? The workflow I described is simply an automatic action that would occur that set the attribute to the desired value before the object is published.

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

nigel dodd

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

Frederik Holljen

Tuesday 12 July 2005 5:25:06 am

I think the sort of problems you have are better to solve through a trigger system. E.g a trigger when an object is about to be published. If you want to do some additional stuff then you can simply write it with a small PHP stubb and connect it to the trigger.