If you're looking up off of a session variable, be sure to take into account what might happen if a user happens to have your site open in multiple windows/tabs. What if you've got a client looking for room rates in different tabs for two different dates or rooms trying to do some comparison shopping? They have tab A open with rates for date A and tab B open for rates for date B. They decide that they like offer #5 on tab A and click the link/submit the form. However, the contents of the session have changed since tab A was originally rendered and you now you actually look up offer #5 from tab B and the client gets something completely different than what they wanted. It may not be a concern for your app, but it is something to consider.
On Oct 24, 3:35 pm, cjrh <caleb.hatti...@gmail.com> wrote: > On Oct 24, 9:48 pm, Brian M <bmere...@gmail.com> wrote: > > > How about include all the calculated values in your form and add in an > > additional field that's a HMAC keyed hash of the others using a key > > that only you know? When the user submits, make sure the rest of the > > field values still combine & hash the same way and then you'll know > > the user hasn't messed with the form. > > Thanks for the comment. It's very clever, but too much work. I am > rather going to keep my calculated values in the server-side session, > and always fetch them from there. The client will only every submit > an index into that server-side hash. I am fairly sure now that this > is the way to go here.