Forms to db's and back (was Re: Displaying text and populating

This WebDNA talk-list message is from

2005

It keeps the original formatting. numero = 61227
interpreted = N
texte = On Feb 24, 2005, at 1:00 AM, Kenneth Grome wrote:Sorry but you lost me here. I cannot imagine any time when will a visitor try to edit data that's contained in a hidden field. They don't even know about hidden fields so of course they won't be editing values in those fields.Are you perhaps talking about using a text field to edit data that was originally entered via textarea? If so, you will lose any line break characters because text fields cannot contain line break characters. This really should be considered a programming error, not a limitation of webdna. If you use the wrong field type you're bound to create problems ...---------------------------That may be fine for intranets, but there are plenty of people on the internet who can and will submit data that will create havoc. For example, some sites include price information as hidden inputs. Those poorly written sites are easy targets. Plus there are all sorts of code injection and XSS techniques. I spend plenty of time trying to groom data before it gets stored on the server. This includes any form of user input that I might look at later (cookies, any form field, mime headers etc.) That's why we now have secure=T by default for variables.I have implemented a practice where I look at all user data, check it with a function, and return it to the user for checking if there are errors. It gets parked in a table in revised or accepted form before I return it to the user with errors or store it in the database.Basically it goes:1. Set up a table with meta data about the on page variables (max length, accept if empty, characters?).2. If no user input, use meta data to create the form.3. If any user input, groom it with functions while storing errors and revised data (trim data for length, date format, illegal characters) in a table.4. If errors, return revised data from the table to the user for correction, else accept the data and notify user.This means I am unlikely to populate a form field from a form variable ever because everything will come from the table after having been groomed.I've got something that has been slightly factored and clean that I can roll up into a tool to show some code on this. I'll make sure that I incorporate the rules that Ken set out pretty clearly. For ease of reference, Ken's summary was:1- To display text on the page from a db field --> use [convertchars]2- To display text on the page from a text formvariable -- don't use anything3- To display text on the page from a textarea formvariable -- use [grep search=%0B&replace=
]4- To populate any text or textarea or hidden field from a db field or from a formvariable --> use [input] every timeI think I'd modify these slightly by never displaying or storing a form variable without grooming it, so I'd only ever use 1, 3 and 4 above.Can I suggest guidelines in the following form:A. From a database to user:(1) any form input populated from a database, should appear inside [input][/input] to eliminate vertical tabs for textareas and quotes for all other form inputs.(2) any page display (aside from form inputs) populated from a database, should appear inside [convertchars][/convertchars] plus %0B to
via grep or an addition for the same effect to the convertchars database.B. From a user to a database:(1) groom the form data first (I use a table with meta data about the variables and functions that prevent unwanted data/injected code). NEVER let unsafe data into your application or on your page! The hackers and phishers are too damn clever.(2) after B(1), you can add/change the database, with the user input by wrapping in [url][/url]. This will preserve the field for editing later.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

On Feb 24, 2005, at 1:00 AM, Kenneth Grome wrote:Sorry but you lost me here. I cannot imagine any time when will a visitor try to edit data that's contained in a hidden field. They don't even know about hidden fields so of course they won't be editing values in those fields.Are you perhaps talking about using a text field to edit data that was originally entered via textarea? If so, you will lose any line break characters because text fields cannot contain line break characters. This really should be considered a programming error, not a limitation of webdna. If you use the wrong field type you're bound to create problems ...---------------------------That may be fine for intranets, but there are plenty of people on the internet who can and will submit data that will create havoc. For example, some sites include price information as hidden inputs. Those poorly written sites are easy targets. Plus there are all sorts of code injection and XSS techniques. I spend plenty of time trying to groom data before it gets stored on the server. This includes any form of user input that I might look at later (cookies, any form field, mime headers etc.) That's why we now have secure=T by default for variables.I have implemented a practice where I look at all user data, check it with a function, and return it to the user for checking if there are errors. It gets parked in a table in revised or accepted form before I return it to the user with errors or store it in the database.Basically it goes:1. Set up a table with meta data about the on page variables (max length, accept if empty, characters?).2. If no user input, use meta data to create the form.3. If any user input, groom it with functions while storing errors and revised data (trim data for length, date format, illegal characters) in a table.4. If errors, return revised data from the table to the user for correction, else accept the data and notify user.This means I am unlikely to populate a form field from a form variable ever because everything will come from the table after having been groomed.I've got something that has been slightly factored and clean that I can roll up into a tool to show some code on this. I'll make sure that I incorporate the rules that Ken set out pretty clearly. For ease of reference, Ken's summary was:1- To display text on the page from a db field --> use [convertchars]2- To display text on the page from a text formvariable -- don't use anything3- To display text on the page from a textarea formvariable -- use [grep search=%0B&replace=
]4- To populate any text or textarea or hidden field from a db field or from a formvariable --> use [input] every timeI think I'd modify these slightly by never displaying or storing a form variable without grooming it, so I'd only ever use 1, 3 and 4 above.Can I suggest guidelines in the following form:A. From a database to user:(1) any form input populated from a database, should appear inside [input][/input] to eliminate vertical tabs for textareas and quotes for all other form inputs.(2) any page display (aside from form inputs) populated from a database, should appear inside [convertchars][/convertchars] plus %0B to
via grep or an addition for the same effect to the convertchars database.B. From a user to a database:(1) groom the form data first (I use a table with meta data about the variables and functions that prevent unwanted data/injected code). NEVER let unsafe data into your application or on your page! The hackers and phishers are too damn clever.(2) after B(1), you can add/change the database, with the user input by wrapping in [url][/url]. This will preserve the field for editing later.-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ William DeVaul

DOWNLOAD WEBDNA NOW!

Forms to db's and back (was Re: Displaying text and populating

2005

Top Articles:

Related Readings: