DTP


 
Lively discussions on the graphic arts and publishing — in print or on the web


Go Back   Desktop Publishing Forum > General Discussions > Web Site Building & Maintenance

Reply
 
Thread Tools Display Modes
Old 05-08-2006, 10:05 AM   #1
Bo Aakerstrom
Member
 
Bo Aakerstrom's Avatar
 
Join Date: Mar 2005
Location: Derby,UK
Posts: 1,321
Default Info from form to database

Does ayone know where I can find out about getting info from a form into a database? Using the info won't be a problem, I've got that bit sorted out.

I realise that I would want to have the option to decide to save or scrap an entry manually, as I don't want to be swamped by spam.

Any thoughts about this that might be good for me to know?

   
__________________
www.boaakerstrom.com
Behance Portfolio
Bo Aakerstrom is offline   Reply With Quote
Old 05-08-2006, 10:35 AM   #2
gary
Member
 
Join Date: Dec 2004
Location: In the heart of Lake Minnetonka
Posts: 337
Default

"save or scrap an entry manually"?
Are you referring to a web server form or an e-mail form?
For a web form you would use CGI/PHP/ASP/... to capture the form variables, validate them and write them into a MySQL/Postgresql/Oracle/MSSQL database.

"PHP MySQL Website Programming" by Lea, Buzzard, White-Cinis, Thomas (WROX).
"PHP and PostgreSQL" by Geschwinde and Schonig (SAMS).

The "Ruby on Rails" intro has you saving form data in a few minutes.
gary is offline   Reply With Quote
Old 05-08-2006, 10:59 AM   #3
iamback
Member
 
iamback's Avatar
 
Join Date: Oct 2005
Location: Amsterdam, NL
Posts: 4,894
Default

Quote:
Originally Posted by Bo Aakerstrom
I realise that I would want to have the option to decide to save or scrap an entry manually, as I don't want to be swamped by spam.
Rather than filtering manually, you could save yourself a lot of trouble and time by letting your webserver do a lot of filtering for you before saving it in a database.

For instance, set a limit to the number of URLs a message may contain. More than that and you'll just let it quietly disappear into the bit bucket. Another trick is to use a cookie - serve a cookie (with random content) when displaying the page with the form, and make that cookie also a hidden field in the form; when receiving the data, check whether the cookie was sent back and matches the field in the form: that will defeat most form-posting scripts.

I'm simplifying a bit (but not a lot!), but you get the idea. It needs to be programmed (but so does putting data into a database) but once there it will save tons of time and aggravation. On the Wikka Wiki site we have a similar system in place that keeps practically all spam out of the system.

   
__________________
Marjolein Katsma
Look through my eyes on Cultural Surfaces (soon!), My ArtFlakes shop and Flickr.
Occasionally I am also connecting online dots... and sometimes you can follow me on Marjolein's Travel Blog
iamback is offline   Reply With Quote
Old 05-08-2006, 12:11 PM   #4
Bo Aakerstrom
Member
 
Bo Aakerstrom's Avatar
 
Join Date: Mar 2005
Location: Derby,UK
Posts: 1,321
Default

Quote:
Originally Posted by gary
The "Ruby on Rails" intro has you saving form data in a few minutes.
Thank's Gary, already had a quick look at Ruby on Rails and the two titles you mention sounds like worthwhile to look into as well.

   
__________________
www.boaakerstrom.com
Behance Portfolio
Bo Aakerstrom is offline   Reply With Quote
Old 05-08-2006, 12:16 PM   #5
Bo Aakerstrom
Member
 
Bo Aakerstrom's Avatar
 
Join Date: Mar 2005
Location: Derby,UK
Posts: 1,321
Default

Quote:
Originally Posted by iamback
Rather than filtering manually, you could save yourself a lot of trouble and time by letting your webserver do a lot of filtering for you before saving it in a database.

For instance, set a limit to the number of URLs a message may contain. More than that and you'll just let it quietly disappear into the bit bucket. Another trick is to use a cookie - serve a cookie (with random content) when displaying the page with the form, and make that cookie also a hidden field in the form; when receiving the data, check whether the cookie was sent back and matches the field in the form: that will defeat most form-posting scripts.

I'm simplifying a bit (but not a lot!), but you get the idea. It needs to be programmed (but so does putting data into a database) but once there it will save tons of time and aggravation. On the Wikka Wiki site we have a similar system in place that keeps practically all spam out of the system.
As usual, I can comprehend about half of what you are suggesting! But I do get the idea...

Thank's for pointing me in the right direction.

Something to get stuck into next week.

   
__________________
www.boaakerstrom.com
Behance Portfolio
Bo Aakerstrom is offline   Reply With Quote
Old 05-08-2006, 03:48 PM   #6
gary
Member
 
Join Date: Dec 2004
Location: In the heart of Lake Minnetonka
Posts: 337
Default

FWIW: I found that the most expedient method of avoiding form-spam is to check that the referrer is the expected submission page; whenever I've been called in to fix a form-spam problem the log typically shows no or the wrong referring page. (These are all sites where the form goes to a specific non-disclosed e-mail address list)
gary is offline   Reply With Quote
Old 05-08-2006, 05:23 PM   #7
iamback
Member
 
iamback's Avatar
 
Join Date: Oct 2005
Location: Amsterdam, NL
Posts: 4,894
Default

Quote:
Originally Posted by gary
FWIW: I found that the most expedient method of avoiding form-spam is to check that the referrer is the expected submission page; whenever I've been called in to fix a form-spam problem the log typically shows no or the wrong referring page. (These are all sites where the form goes to a specific non-disclosed e-mail address list)
Referrer is actually very unreliable. many browsers offer the option of not sending it, and many security systems also hide it - often without their user knowing or understanding. It may even be part of a corporate sytem or policy and outside of the user's control.

I'll bet you'll have an easier job explaining cookies need to be accepted than that the referrer needs to be sent - let alone how to configure that, if it is in the user's power at all.
  • If the referrer is there and doesn't match: wrong
  • If the referrer is there and matches: right
  • If the referrer isn't there: use something else!

(BTW checking for a referrer is also often used to avoid images from being "stolen" - the good routines for that do take into account that referrer may not be there and that this actually is a valid situation.)

   
__________________
Marjolein Katsma
Look through my eyes on Cultural Surfaces (soon!), My ArtFlakes shop and Flickr.
Occasionally I am also connecting online dots... and sometimes you can follow me on Marjolein's Travel Blog
iamback is offline   Reply With Quote
Old 05-08-2006, 09:40 PM   #8
gary
Member
 
Join Date: Dec 2004
Location: In the heart of Lake Minnetonka
Posts: 337
Default

Quote:
Originally Posted by iamback
Referrer is actually very unreliable.
In this case the existing logs indicated referrer in every valid case and none in the spam cases - confirmed by observing the preceeding (or lack thereof) retrieval of the submittal page.

But -- noting that I said it was "expedient" -- you are correct in that referrer is not absolutely reliable.

(I only get called in -- to make a quick-fix -- on those sites when the site builder is in over his head. To make things worse some of the sites were in CFM - with which I was only tangentially familiar.)
gary is offline   Reply With Quote
Old 05-09-2006, 02:07 AM   #9
iamback
Member
 
iamback's Avatar
 
Join Date: Oct 2005
Location: Amsterdam, NL
Posts: 4,894
Default

Quote:
Originally Posted by gary
(I only get called in -- to make a quick-fix -- on those sites when the site builder is in over his head. To make things worse some of the sites were in CFM - with which I was only tangentially familiar.)
ColdFusion? Somewhat powerful, but oh, so ugly. It looks like programming but isn't. OK (but far from easy any more) if you come from a markup background, endlessly confusing if you come from a programming background. Been there, done that (cause I had to), won't go back (if I can avoid it).

   
__________________
Marjolein Katsma
Look through my eyes on Cultural Surfaces (soon!), My ArtFlakes shop and Flickr.
Occasionally I am also connecting online dots... and sometimes you can follow me on Marjolein's Travel Blog
iamback is offline   Reply With Quote
Old 05-09-2006, 08:38 AM   #10
dthomsen8
Member
 
dthomsen8's Avatar
 
Join Date: Aug 2005
Location: Philadelphia, PA 19130
Posts: 2,158
Default PHP/MySQL is a good way to go.

PHP/MySQL for capturing information from a form is a good way to go, and can include a good deal of data checking, too. There are good canned procedures and good explanations in books, so you don't have to learn a lot of PHP to get it going. Just be careful to get the user name and password requirements of your web hosting company right.

I did one a few years ago, but my client required some complex results, as well as data checking, so it took me a while to get it right.

Let us know which way you go.
dthomsen8 is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Form Processor Cleo8 Web Site Building & Maintenance 2 02-14-2007 02:55 AM
Database publishing w/DTP tools? himalaya General Publishing Topics 14 08-25-2006 12:41 PM
Database or XML? Synchronisation with Quark the_doctor Print Production & Automation 1 02-06-2006 07:31 AM
Web Site Form Spamming Tim Lodge Web Site Building & Maintenance 8 10-22-2005 09:21 AM


All times are GMT -8. The time now is 08:45 AM.


Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Contents copyright 2004–2014 Desktop Publishing Forum and its members.