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

This WebDNA talk-list message is from

2005

It keeps the original formatting. numero = 61267
interpreted = N
texte = I want to keep certain information out of the databases and make sure that some information is entered with a record. In the worst case, a malicious user will try to upload something that harms the server, in other cases, the user simply makes a keypunch error. In order to groom the data, the formvariables are added to the table, validated and/or changed as needed. I validate for proper email address format, some fields cannot be too long or blank, some are alphanumeric, some are numbers only, date formats must be correct and the dates must be valid, some must be unique within the database. (I have not code all of these validation functions because they have not been needed yet.) I can't trust client side validation to solve this problem or the databases will be corrupted. If there are no errors, the data can be appended or displayed. If there are errors, the form is returned and errors flagged for the user. For example, as Ken points out, most users will never change a hidden field or a cookie, but some could. If you do not guard against these, your users could get a malfunctioning site or some form of XSS (cross site scripting). The simple routine I have worked out seems to limit this problem. The meta data is basically a table that tells the script what validation routines are to be run, how long or short the data can be, how it should be displayed in the form (text, hidden, textarea, select) and things like that. I understand that I could handcode the pages, but that is too much work since I can have meta data that will do the work for me. By making changes in the table, the script generates the right form and options. I use Excel to edit the table. Every table makes a new editing page for a database. That is far easier than handcoding. Some databases handle validation internally when you define the field type or store procedures to do this and reject invalid data. Since WebDNA is not so limited, I created a workaround. At some point I will upload a simple example under some sort of open source license. I was hoping to work it into digger.tpl as I have made some small changes to that to make it even more useful. What I'd like to see is others add validation functions and perhaps additional formatting options. Bill-----Original Message-----From: Terry Wilson Sent: Wed, 2 Mar 2005 10:00:39 -0500To: "WebDNA Talk" Subject: Re: Forms to db's and back (was Re: Displaying text and populating form fields)Bill,Can you elaborate on your grooming technique a little bit? Not sure I understand what you mean about holding meta data or how you use it.Thanks,TerryAt 2:00 AM -0800 2/28/05, devaulw@onebox.com wrote:>>I have implemented a practice where I look at all user data, check >itwith a function, and return it to the user for checking if there >areerrors. It gets parked in a table in revised or accepted form >before Ireturn 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 >(maxlength, 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 >andrevised data (trim data for length, date format, illegal >characters) ina table.>4. If errors, return revised data from the table to the user >forcorrection, else accept the data and notify user.>>This means I am unlikely to populate a form field from a form >variableever because everything will come from the table after >having beengroomed.>>I've got something that has been slightly factored and clean that I >canroll up into a tool to show some code on this.-------------------------------------------------------------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/-------------------------------------------------------------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:

I want to keep certain information out of the databases and make sure that some information is entered with a record. In the worst case, a malicious user will try to upload something that harms the server, in other cases, the user simply makes a keypunch error. In order to groom the data, the formvariables are added to the table, validated and/or changed as needed. I validate for proper email address format, some fields cannot be too long or blank, some are alphanumeric, some are numbers only, date formats must be correct and the dates must be valid, some must be unique within the database. (I have not code all of these validation functions because they have not been needed yet.) I can't trust client side validation to solve this problem or the databases will be corrupted. If there are no errors, the data can be appended or displayed. If there are errors, the form is returned and errors flagged for the user. For example, as Ken points out, most users will never change a hidden field or a cookie, but some could. If you do not guard against these, your users could get a malfunctioning site or some form of XSS (cross site scripting). The simple routine I have worked out seems to limit this problem. The meta data is basically a table that tells the script what validation routines are to be run, how long or short the data can be, how it should be displayed in the form (text, hidden, textarea, select) and things like that. I understand that I could handcode the pages, but that is too much work since I can have meta data that will do the work for me. By making changes in the table, the script generates the right form and options. I use Excel to edit the table. Every table makes a new editing page for a database. That is far easier than handcoding. Some databases handle validation internally when you define the field type or store procedures to do this and reject invalid data. Since WebDNA is not so limited, I created a workaround. At some point I will upload a simple example under some sort of open source license. I was hoping to work it into digger.tpl as I have made some small changes to that to make it even more useful. What I'd like to see is others add validation functions and perhaps additional formatting options. Bill-----Original Message-----From: Terry Wilson Sent: Wed, 2 Mar 2005 10:00:39 -0500To: "WebDNA Talk" Subject: Re: Forms to db's and back (was Re: Displaying text and populating form fields)Bill,Can you elaborate on your grooming technique a little bit? Not sure I understand what you mean about holding meta data or how you use it.Thanks,TerryAt 2:00 AM -0800 2/28/05, devaulw@onebox.com wrote:>>I have implemented a practice where I look at all user data, check >itwith a function, and return it to the user for checking if there >areerrors. It gets parked in a table in revised or accepted form >before Ireturn 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 >(maxlength, 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 >andrevised data (trim data for length, date format, illegal >characters) ina table.>4. If errors, return revised data from the table to the user >forcorrection, else accept the data and notify user.>>This means I am unlikely to populate a form field from a form >variableever because everything will come from the table after >having beengroomed.>>I've got something that has been slightly factored and clean that I >canroll up into a tool to show some code on this.-------------------------------------------------------------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/-------------------------------------------------------------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/ devaulw@onebox.com

DOWNLOAD WEBDNA NOW!

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

2005

Top Articles:

Related Readings: