Symphony.

How do I prevent users from tampering with my forms and injecting a <input type="hidden" name="id" value="33" /> themselves to edit existing entries?

Edit: I have written an extension to do that.

I’m not sure if I understand your question. Could you please elaborate on this issue?

When using events, the docs tell me to add a hidden input name=’id’ to the form in order to edit entries (leaving it out creates entries).

What measures are there to prevent users from adding that input (or the POST-value) themselves?

Nothing.

If you want the extra security you’ll need to add some custom PHP inside the event to authenticate in whatever context you need (checking a user cookie for example).

But thats not possible without changing the core, right?

That is a real pity, as it makes it impossible to create, for example, a comment-system for blogs…

Not necessarily the core, but you can edit the individual event PHP files.

protected function __trigger(){

    // your custom code here

    include(TOOLKIT . '/events/event.section.php');
    return $result;
}

Then be sure to disable saving over the Event from within Symphony:

public static function allowEditorToParse(){
    return false;
}

I use this method quite a lot where a comment may have a “Moderation” select box with possible values “Pending”, “Approved” and “Declined” so that a moderator author can choose what comments are displayed publicly. In the Event PHP I set the moderation value to “Pending” rather than leaving it in the HTML:

$_POST['fields]['moderation'] = 'Pending';

Ah, I see. What exactly do you mean by saying

Then be sure to disable saving over the Event from within Symphony

and what does allowEditorToParse() mean and do?

Another solution I had in mind was: Automatically remove any hidden inputs from the forms and replace them by a unique identifier. Save all the removed values in the session and fetch them once the form is submitted. That way all relevant settings can be set in the form but still be protected from tampering with.

Alternatively, there should be a couple of flags for each Event where users can set “Enable Editing”, “Enable saving” and what not (in the code and maybe in the Events-dialog).

Does this mean that front end forms aren’t safe “out of the box”, but need extra care?

@nickdunn - What you are saying is that without that extra code in the Event itself, users could somehow set the moderation bit to ‘approved’?

and what does allowEditorToParse() mean and do?

Every time you save a Data Source or Event, the PHP file in which said object manifests itself is created, from a template file. Do when you create an Event, Symphony copies the template file and saves it as your new event. If you then make changes to the PHP yourself, Symphony doesn’t know this and will recreate the file from the template.

Changing the return value of the allowEditorToParse function prevents Symphony from parsing and editing the Event. Change the value then return to Components list and click on the event name. Instead of the form to edit its name and section, you see a more limited view. The same goes for Data Source. It preserves your changes, changing the file from a native Symphony file, to a custom file.

Does this mean that front end forms aren’t safe “out of the box”, but need extra care?

It depends entirely what you’re using them for. In a standard blog context, they’re perfectly safe. If all the user can tamper with is the ID to which post the comment is assigned, who cares, it’s the same as visiting the other blog post and commenting.

are saying is that without that extra code in the Event itself, users could somehow set the moderation bit to ‘approved’

Yes. If they were to guess that this is the correct value. But forcing it inside the event prevent this from happening, no matter what the value of fields[moderation] is.

I believe that the forthcoming Members extension has some level of control over which members can trigger which events. And future versions of Symphony will undoubtedly have more granular control over the way in which events work. But for now, customising is your best option.

One such example I do on almost a daily basis is adding user authentication to events. Instead of sending the user ID in a hidden field (which can be tampered with), my custom login manager class is included into the event and I set the POST array from that value:

$user = LoginManager::getLoggedInUser();
$_POST['fields']['user'] = $user->id;

The first rule of web development — never trust user input ;-)

nickdunn: But users could not only edit the article-entry-id, to wich the comment will be associated but also provide a comment-entry-id and thus edit other peoples comments!

I have created a little extension to stop users from editing entries by exploiting the issue mentioned above: Filter: No Editing of Entries. I still think that Symphony should offer a way to do this though.

I use this method quite a lot where a comment may have a “Moderation” select box with possible values “Pending”, “Approved” and “Declined” so that a moderator author can choose what comments are displayed publicly. In the Event PHP I set the moderation value to “Pending” rather than leaving it in the HTML:

@nickdunn: Could you post an example of an edited Event?

@phoque: Thanks, I’ll have a look at your filter today.

Nice one phoque, it’s a good solution. In the past I have done a similar thing by unsetting the ID, but it’s nice to have a Symphony-esque solution so that events don’t need to be customised.

unset($_POST['id']);

If editing of entries is required, it’s best to take these values from the URL parameters instead ($this->_env) because if you’re already using some form of authentication, the user will only be able to view entries related to them anyway.

thoersson, example of an edited event is above. Take a look at the __trigger() function inside the PHP, and insert your custom code:

...

public static function allowEditorToParse(){
    return false; // change from "true:
}

protected function __trigger(){

    // your custom code here
    unset($_POST['id']);
    $_POST['fields']['moderation'] = 'Pending';

    include(TOOLKIT . '/events/event.section.php');
    return $result;
}

nickdunn: Thanks.

So essentially, it would be ideal if you could define the incoming data from an event in a similar way as the outgoing data from a datasource.

ashooner: I agree.

When I first saw the events-editor I was confused on how few options it actually offered. :-)

@phoque: Is selecting the filter for an event all it takes to enable the non-editing feature? Or should something be added to the html form as well? I’m not sure from reading the documentation.

Yep, simply select it. Hints on how to make the documentation more clear are welcome. :-)

Would be possible to build a extension that prevents editing on a section in the backend? Lets say a contact form in the front end for exemple, i could turn off editing in that section, so nobody could chage the contacts information in the backend.

I work with a feel clients that like to view their websites related emails trough the websites control panel, and as a contact info it does not need to be chenged at all, just viewed.

Does it make sense? could it be made?

That should be possible out-of-the-box with the Author Roles extension.