[EMAIL PROTECTED] writes: > Looking at CGI::EncryptForm that Perrin mentioned, it appears that that > module would address this concern by storing client-side in a single > encrypted string that gets put in one hidden form variable. That also > avoids having to verify more than once.
It is always good to validate the data even if it was encrypted. It is also generally a good idea not to give the user any secrets, even if they are encrypted. In other words, avoid trusting the user. [EMAIL PROTECTED] writes: > No, this just means that input must be validated once again when the > last «really, really sure ?» button is depressed. Conceptually, this > divides the pages of your site into two categories (not unlike the > view vs. controller distinction in Model-View-Controller paradigm for > GUIs): those that just interact with the user and do the navigation, > and those that actually have side effects such as writing data into your > database, sending e-mails, placing orders etc. It is MVC. However, instead of thinking of pages, I like to think in terms of tasks. The same task that renders the form also validates and executes it. In the case of execution, the result is a redirect described by the site's state machine. A form in our world has four states: execute_empty (fill in defaults), execute_ok, execute_other (e.g., cancel or sub form), and execute_unwind (coming back from a sub form). All of these paths go through the same task. Rob
