Prev: Elegance is the goal... Sticky form submit help
Next: New to PHP and the list
From: Tamara Temple on 11 Sep 2010 12:52
I have a general question and am looking for best practices.

Suppose I present a user with a form for editing an entry in a table,
i.e., the form has filled in values from the existing table entry.

Now, suppose they click on 'submit' without making any changes in the
form. (Perhaps, say, rather than clicking 'Cancel' or 'Return to Main'
or some other option which would get them out of that screen without
submitting the form).

Is it worth the overhead of passing along the previous values in the
table in hidden fields so that fields can be checked to see if they've
been updated or not after the submit? Or is it worth reloading the old
values from the table to check against the newly submitted form? Or is
all that overhead not worth the time because an update that overwrites
existing values with the same values is not that onerous?

(Is that question clear enough?)
From: Tamara Temple on 12 Sep 2010 03:38

On Sep 11, 2010, at 10:46 PM, Shawn McKenzie wrote:
> It could however be a problem if there is a BOT or something that
> continually submits to your page. In that case (and in general) I
> would
> recommend using a form token that helps guard against this.

I've seen this on some sites, but I'm unclear how to implement this.
How is this generally done?

Thanks,
Tamara

From: Tamara Temple on 12 Sep 2010 03:40

On Sep 11, 2010, at 9:27 PM, viraj wrote:

> On Sat, Sep 11, 2010 at 10:22 PM, Tamara Temple <tamouse.lists(a)gmail.com
> > wrote:
>> I have a general question and am looking for best practices.
>>
>> Is it worth the overhead of passing along the previous values in
>> the table
>> in hidden fields so that fields can be checked to see if they've been
>
> without storing all the values in respective hidden fields, calculate
> a 'checksum' on data and store in one hidden field. after the submit
> and before you decide on the update, you can calculate the checksum of
> submitted data, compare against the hidden field checksum and take the
> decision.
>
> if you maintain a session, storing checksum in session instead of
> client side (hidden field in form) will be more safe/secure and will
> help in improving the mechanism (persistent classes, serialized data
> etc)

Ah, interesting idea, I hadn't thought of that as an option. Yes, it
makes sense.
Also makes sense to store it in a session variable instead of on the
form.

Thanks,
Tamara

From: Tamara Temple on 12 Sep 2010 17:12

On Sep 12, 2010, at 3:34 PM, Robert Cummings wrote:

> On 10-09-11 12:52 PM, Tamara Temple wrote:
>> I have a general question and am looking for best practices.
>>
>> Suppose I present a user with a form for editing an entry in a table,
>> i.e., the form has filled in values from the existing table entry.
>>
>> Now, suppose they click on 'submit' without making any changes in the
>> form. (Perhaps, say, rather than clicking 'Cancel' or 'Return to
>> Main'
>> or some other option which would get them out of that screen without
>> submitting the form).
>>
>> Is it worth the overhead of passing along the previous values in the
>> table in hidden fields so that fields can be checked to see if
>> they've
>> been updated or not after the submit? Or is it worth reloading the
>> old
>> values from the table to check against the newly submitted form? Or
>> is
>> all that overhead not worth the time because an update that
>> overwrites
>> existing values with the same values is not that onerous?
>>
>> (Is that question clear enough?)
>
> I use database table to object mapping classes. The base class sets
> a dirty bit if a field actually changes. If an attempt is made to
> save the data and no dirty bits are set, then the save method
> returns true for a successful save, but no commit to database is
> made since nothing has changed. In this way I never think about the
> problem beyond the original implementation of the base class.

Ok, but how do you detect if a field changes? The specific
implementation between application and data storage is probably moot
until you figure that part out.
From: Tamara Temple on 12 Sep 2010 18:04

On Sep 12, 2010, at 4:28 PM, Robert Cummings wrote:

> On 10-09-12 05:19 PM, Michael Shadle wrote:
>> On Sun, Sep 12, 2010 at 2:12 PM, Tamara Temple<tamouse.lists(a)gmail.com
>> > wrote:
>>> Ok, but how do you detect if a field changes? The specific
>>> implementation
>>> between application and data storage is probably moot until you
>>> figure that
>>> part out.
>>
>> +1
>>
>> without talking to the server, or accessing it in the DOM somewhere,
>> the client has no access to the data. is it done via ajax/javascript?
>> some action onchange/onkeypress/etc. and check it against a variable
>> that was set on pageload?
>
> Sorry, I thought this was about committing to the database versus
> sending back to the web server. I must have misread the original
> requirement. If trying to trap before submitting the form to the
> webserver then JavaScript is necessary. You can't do this on upload
> fields though.

Actually, even the client-side aspect isn't good enough -- they could
simply retype the same value in the field. Also, I'd like to not rely
on JavaScript alone to indicate that there's been a change, since, as
Ashley points out, someone could simply send up a form without
bothering with JavaScript. I'm talking about checking whether the
field has changed on the server-side of things, specifically.

So far, it seems the contenders are:

1) just update the record if there's not a big load on the server
2) use a checksum before populating the form for display and after
receiving the post from the client, storing the initial checksum in a
session variable
3) compare the submitted values against the values in the data base,
since you can't trust what is coming from the client, although this
does put an additional load on the server which might not be good if
there's already a big load on the server



 | 
Pages: 1
Prev: Elegance is the goal... Sticky form submit help
Next: New to PHP and the list