Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Is using 'Cookies' impractical for 'Contact Us' forms?

by newbie00 (Beadle)
on Jul 07, 2006 at 06:54 UTC ( #559723=perlquestion: print w/replies, xml ) Need Help??
newbie00 has asked for the wisdom of the Perl Monks concerning the following question:


Is using 'Cookies' impractical for 'Contact Us' forms?

What about those folks whose computers don't allow cookies to be enabled (e.g. their PC at work)? How to allow those folks to use the E-mail form to 'Contact Us'?

Posting phone#'s is getting abused at times in similar ways as mining E-mail addresses for mailing lists. I see more and more websites having E-mail-only (via E-mail forms) as the only method for contacting them.

I want to use cookies for session management where the cookie expires. This includes image verification that uses cookies. I'm trying to create some resistance to bots; multiple submissions; protect website in shared environments; etc.

Is this a Catch-22? Do I have to decide to just not have everyone with the ability to 'Contact Us'?

Currently, I am setting up to use cookies with a database for sessions validation, but am I locking out too many people if I use this method of security, thus making it 'impractical'?

Should/Could I use another method instead of cookies, e.g. a file that is deleted after some time period which would contain the same info as a cookie and still allow for comparing the session entry stored in a database? If so, how?

Thanks in advance.

  • Comment on Is using 'Cookies' impractical for 'Contact Us' forms?

Replies are listed 'Best First'.
Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by Corion (Pope) on Jul 07, 2006 at 06:58 UTC

    What problem are you trying to solve with cookies and how does it relate to the "Contact Us" form?

    If you just have an input form into which people can enter their question and their email address for the response, what do you need cookies for? Maybe my idea of a "Contact Us" form is different from yours.

      Thanks for your reply.

      The contact form will probably using "image verification" which uses cookies for session management.

      Several folks I have been conversing with are tired of the spam they receive from their 'Contact Us' and other forms (e.g. bogus account signups, multiple submissions, bots, etc.), so I'm trying to be proactive.

        If you are concerned about locking people out who might not want to or are not able to receive cookies then you should equally be concerned about those people who you are deliberately excluding by using "image verification" (Known as CAPTCHA to most of us.) CAPTCHA is documented as being inaccessible to a significant proportion of the population, and is also not as secure as many people seem to think they are. To be honest the inaccessibility issue should make most people think twice about using them these days as a number of countries have laws requiring equality of access to web sites.


        "Hello, I am a blind person and I'm unable to navigate your website"

        I would deal with the problem when it comes to it instead of overdesigning the most basic functionality people need to tell you about faults with the website. As long as your Contact Us form does not send mail and maybe has some (IP-based) throttling, it should be possible to stem a flood of bots.

        Several folks I have been conversing with are tired of the spam they receive from their 'Contact Us' and other forms (e.g. bogus account signups, multiple submissions, bots, etc.), so I'm trying to be proactive.

        If it really is just a 'Contact Us' form I wouldn't worry. There's a reason for evil folk to attack account registration forms - but contact us forms? Very rarely a problem in my experience.

Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by jhourcle (Prior) on Jul 07, 2006 at 13:13 UTC

    Simple answer : Yes

    Long answer : If you actually want users to contact you, you should ensure the lowest possible barrier to entry. That includes no javascript, no cookies, no 'mailto:' form actions, no CAPTCHAs, etc.

    I would assume that your contact form mails to a limited list of people, and doesn't take a 'to' e-mail address from the form itself. (you might take an 'about' (subject) heading from the form, and translate that behind the scenes to the appropriate e-mail address, but don't accept a tainted e-mail)

    If so, the only people they can spam are your company -- and when you have someone flooding one mailbox, it's annoying, but easily deleted. They'd have been able to have done it just as easily by getting an e-mail address of an employee there, or waiting for you to respond to the form submission, and then flooding you.

    I don't know your exact situation, and why you believe there to be this need, but I don't think CAPTCHAs are the way to go (especially because they needlessly exclude people with poor vision). I'd suggest instead taking a look at Limit submissions over time?.

Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by jdtoronto (Prior) on Jul 07, 2006 at 13:39 UTC
    Going WAY WAY back to the orignal post I would like to add a comment on sessioning.

    My WebApps rely heavily on sessioning too, but it is easy to get around the cookie issue. Cookies are nice, and I find about 92% of visitors to my main App have cookies enabled - provided the cookie domain and the browsed domain are identical. But you CAN maintain session state using parameters, you don't need to use cookies.


Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by TedPride (Priest) on Jul 07, 2006 at 15:44 UTC
    The easiest thing to do is just require people to enter some simple piece of information, like their state, in one of the form fields. Then name the field something random (and give it a max length of something other than 2...) so the bots can't automatically identify what type of field it is. 99% of the bots should be stymied.
Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by Moron (Curate) on Jul 07, 2006 at 14:45 UTC
    A common and effective approach is to require users to register on the site before giving them the ability to fill out the contact form (amongst other things). You ensure that the email address is unique for an account on your site, e.g. by making it the primary key in the database. Before their account is activated (enabling user privileges including contact) they are sent an email with an activation code (usually a link in the email they can simply click on to activate and log in first time). Only when their account is activated and they are logged in should they be given access to pages that write to your site. If a user clicks on contact without logging in he is prompted to either log in or register.


    Free your mind

Re: Is using 'Cookies' impractical for 'Contact Us' forms?
by newbie00 (Beadle) on Jul 07, 2006 at 17:36 UTC
    Thanks all!

    For my 'Contact Us', I'm using a helpdesk ticket software that requires registration before posting.

    The issues I've heard about is with people with too much time on their hands spamming the signups form with no intention of logging in, leaving alot of fake accounts setup in system. I'm trying to institute safeguards up-front to prevent this.

    What I'd like to do now after reading the wonderful feedback in this thread, is to find a way to limit submissions -- both on the signup page AND the ticket submissions page. For a 'Contact Us' page for legitimate visitors, I would like a way that doesn't use cookies IF it's deemed impractical for this purpose. If it's not impractical, I'd like to use cookies or parameters or whatever is effective.

    What are the steps involved to limit submissions? Also, what's a good time period to use once the signups form has been submitted, before another can be submitted? I would probably use this technique to control the # of tickets submitted once someone is inside the system, if that feature is not already available.

    I am a newbie at sessions management techniques, but am willing to learn.

    Any help will be greatly appreciated.

    Thanks again.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://559723]
Approved by Corion
and the fog begins to lift...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (2)
As of 2018-01-21 06:50 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (227 votes). Check out past polls.