In order to make the fields non-editable you have to assume things about the functionality of the user's browser. If the user gets to supply his own browser all bets are off. Imagine how you would support non-editable fields if the user connected to your server with "telnet www.victim.com 80".

The usual solution is to establish a session state, so you can validate that hidden or non-edit fields really have the right values in them, all the fields are there, and the user didn't add anything (that matters.)

In the case of a simple deletion, you might want to repeat whatever logic you used to determine that the user is authorized to delete this object, instead of checking the session state. That could be less code, or more, depending on how your authorization works.

Basically, you add an empty 'readonly' attribute to the markup.

$form->field( name => 'field_name', readonly => 1);

For checkboxes, you can use disabled

$form->field( name => 'choices', disabled => 'disabled');

In response to the pedants, this is not a security issue. It is a usability question. The form is showing a different view of the same data to perform different operations on it.

For example "make a duplicate record", or "delete record". It doesn't make sense for the user to modify those fields if the action ignores those modifications.

The permissions handling is still managed by the server. If a user added his own query parameter in the request "&destroy_everything=1", doesn't mean the server will obey it.

Chris

Do you need a form at all?

All you're after is a yes or no from the user. Perhaps display the data in a table and add two links

<a href="delete.cgi?confirm=1">confirm</a>
<a href="delete.cgi?confirm=0">cancel</a>
[download]

Have the script take care of if and what is to be deleted. You really need to heed quester's note of caution about authorisation though.