Another approach to prevent form submission by spiders

17 views
Skip to first unread message

Alexander Obuhovich

unread,
Apr 13, 2010, 1:59:46 PM4/13/10
to In-Portal Development
Today most popular approach is to place captcha code on form to verify, that humans (not search engines) are submitting site forms. More dirty captcha image is, more chances are spider/bot won't be able to recognize it. On the other hand it makes form submitting uncomfortable for users. Also captcha is used only on forms, when user is not logged in.

Here is approach, that is not using captcha, but still provides same level of protection:
  1. after page with form is loaded, then send ajax request to server
  2. in ajax responce send random name and random value + save both to session
  3. when ajax responce is received, then dynamically add hidden field with received name and value
  4. when form is submitted, then check, that submitted value matches generated one from session
We are generating random hidden field name to allow same form to be submitted from different tabs of same browser, when we have same user session.
Because of spiders don't execute page javascript this approach can work.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

Dmitry Andrejev

unread,
Apr 13, 2010, 2:59:28 PM4/13/10
to in-por...@googlegroups.com
This is quite interesting idea!

I guess, the only down site user needs to have a Cookie enabled, but even then we should be able to pass SID in Get for verification?


DA.

Alexander Obuhovich

unread,
Apr 13, 2010, 3:02:03 PM4/13/10
to in-por...@googlegroups.com
Sure, no need for cookies, since session will switch to get mode in that case, but still will exist. Captcha also uses session to store generated code, so no change here.

S.G.

unread,
Apr 14, 2010, 3:48:12 AM4/14/10
to In-Portal Development Team
Small correction: for correct simultaneous form submissions, two
hidden fields should be dynamically added, one with name like
"verification_key" and another with name like "verification_value",
also this pair is stored on server in session array called like
"verification_pairs" with "verification_key" as key and
"verification_value" as value. Then on submission we take session
array element with passed key and compare passed value to stored one.
Sure, also we verify that both key and value have been passed, and
passed key exists in session array.


On Apr 13, 10:02 pm, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> Sure, no need for cookies, since session will switch to get mode in that
> case, but still will exist. Captcha also uses session to store generated
> code, so no change here.
>

> On Tue, Apr 13, 2010 at 9:59 PM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
>
>
> > This is quite interesting idea!
>
> > I guess, the only down site user needs to have a Cookie enabled, but even
> > then we should be able to pass SID in Get for verification?
>
> > DA.
>

> > On Tue, Apr 13, 2010 at 12:59 PM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> >> Today most popular approach is to place captcha code on form to verify,
> >> that humans (not search engines) are submitting site forms. More dirty
> >> captcha image is, more chances are spider/bot won't be able to recognize it.
> >> On the other hand it makes form submitting uncomfortable for users. Also
> >> captcha is used only on forms, when user is not logged in.
>
> >> Here is approach, that is not using captcha, but still provides same level
> >> of protection:
>

> >>    1. after page with form is loaded, then send ajax request to server
> >>    2. in ajax responce send random name and random value + save both to
> >>    session
> >>    3. when ajax responce is received, then dynamically add hidden field


> >>    with received name and value

> >>    4. when form is submitted, then check, that submitted value matches

Dmitry Andrejev

unread,
Apr 14, 2010, 11:05:34 PM4/14/10
to in-por...@googlegroups.com
Thanks Sergey,

For me both ways sound like going to work - so we just need to decide the path we want to go, do the task and move forward. It would be great if we can add something like this to 5.1.0 release which mostly developed by Alex. For some time he'll be quite busy with some other tasks for 5.1.0 including minimizing JS and Submission form improvements.

Would you be interested in implementing your approach on some test form in 5.1.x branch?

Thanks!


DA.

--
To unsubscribe, reply using "remove me" as the subject.

Dmitry Andrejev

unread,
Apr 17, 2010, 9:40:11 PM4/17/10
to in-por...@googlegroups.com
Sergey - no pressure if you don't think you won't be able to participate with development here. Even though we'd like to see more of your involvement in the project considering your experience with the system :)

DA.

Dmitry A.

unread,
Apr 26, 2010, 9:01:43 AM4/26/10
to In-Portal Development Team
New task has been filed here:

715: Replacement for CAPTCHA functionality

http://tracker.in-portal.org/view.php?id=715

DA.

On Apr 17, 8:40 pm, Dmitry Andrejev <dandre...@gmail.com> wrote:
> Sergey - no pressure if you don't think you won't be able to participate
> with development here. Even though we'd like to see more of your involvement
> in the project considering your experience with the system :)
>
> DA.
>
> On Wed, Apr 14, 2010 at 10:05 PM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
>
>
> > Thanks Sergey,
>
> > For me both ways sound like going to work - so we just need to decide the
> > path we want to go, do the task and move forward. It would be great if we
> > can add something like this to 5.1.0 release which mostly developed by
> > Alex. For some time he'll be quite busy with some other tasks for 5.1.0
> > including minimizing JS and Submission form improvements.
>
> > Would you be interested in implementing your approach on some test form in
> > 5.1.x branch?
>
> > Thanks!
>
> > DA.
>
Reply all
Reply to author
Forward
0 new messages