You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Ed Park <ep...@athenahealth.com> on 2001/01/05 01:52:49 UTC
getting rid of multiple identical http requests (bad users double-clicking)
Does anyone out there have a clean, happy solution to the problem of users
jamming on links & buttons? Analyzing our access logs, it is clear that it's
relatively common for users to click 2,3,4+ times on a link if it doesn't
come up right away. This not good for the system for obvious reasons.
I can think of a few ways around this, but I was wondering if anyone else
had come up with anything. Here are the avenues I'm exploring:
1. Implementing JavaScript disabling on the client side so that links become
'click-once' links.
2. Implement an MD5 hash of the request and store it on the server (e.g. in
a MySQL server). When a new request comes in, check the MySQL server to see
whether it matches an existing request and disallow as necessary. There
might be some sort of timeout mechanism here, e.g. don't allow identical
requests within the span of the last 20 seconds.
Has anyone else thought about this?
cheers,
Ed
Re: Javascript - just say no(t required)
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Les" == Les Mikesell <le...@home.com> writes:
Les> I think it is also very reasonable to store user-selected preferences
Les> in cookies, especially for things likes sizes, colors, fonts for
Les> certain pages. Why should the server side have to store millions
Les> of things like that? Even if it does, the choices may be different
Les> for the same user running a different browser. Normally you
Les> would have some default that would work for the cookie-challenged
Les> folks anyway.
Please remember that the cookie space is spec'ed to be limited. So
your cookie may get pushed out for others. So there'd better be a way
to trivially reload all that stuff, or your customers will be angry.
Might as well be nice, store the info server side, and treat it
like a login.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Javascript - just say no(t required)
Posted by Les Mikesell <le...@home.com>.
----- Original Message -----
From: "dreamwvr" <dr...@dreamwvr.com>
To: "Randal L. Schwartz" <me...@stonehenge.com>
Cc: "Gunther Birznieks" <gu...@extropia.com>; <mo...@apache.org>
Sent: Friday, January 05, 2001 12:00 PM
Subject: Re: Javascript - just say no(t required)
> hi,
> Seems to me the only reasonable usage for cookies that does not
> seem to be abuse.org is as a temporary ticket granting system.. so
> the next time you want to get a byte you need a ticket to goto the
> smorg..
I think it is also very reasonable to store user-selected preferences
in cookies, especially for things likes sizes, colors, fonts for
certain pages. Why should the server side have to store millions
of things like that? Even if it does, the choices may be different
for the same user running a different browser. Normally you
would have some default that would work for the cookie-challenged
folks anyway.
Les Mikesell
lesmikesell@home.com
Re: Javascript - just say no(t required)
Posted by dreamwvr <dr...@dreamwvr.com>.
hi,
Seems to me the only reasonable usage for cookies that does not
seem to be abuse.org is as a temporary ticket granting system.. so
the next time you want to get a byte you need a ticket to goto the
smorg..
Best Regards - dreamwvr@dreamwvr.com
Re: Javascript - just say no(t required)
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Gunther" == Gunther Birznieks <gu...@extropia.com> writes:
Gunther> There's a lot of similar FUD about using cookies (not accepted on
Gunther> PDAs, people scared of them, etc). Personally, I don't like to program
Gunther> using cookies and I have my browser explicitly warn me of the cookie
Gunther> before accepting (which does slow down my browsing experience but is
Gunther> most interesting),, but the reality is that shedloads of sites use
Gunther> them to enhance the user experience but don't make it a problem if
Gunther> they don't go and use them.
I'm fine with requiring and using cookies for short-term session
management, but for long term authentication, they presume "one user
== one browser", and that's patently false.
If you must use them for long term identification, make it very clear
that I'm "logged in", and give me a quick way to "log out", and let me
"log in" from a different browser, and automatically "log me out"
after 4 hours or so in case I forget. :) And don't do that merely by
browser cookie expiration... make the server distrust any cookie after
that time, which means you have to generate a unique cookie on each
login.
Gunther> Speaking of which, I guess the non-use of Cookies and
Gunther> JavaScript would make a great NY Resolution...
What does New York have to do with it? :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Javascript - just say no(t required)
Posted by Gunther Birznieks <gu...@extropia.com>.
Yeah, but in the real world regardless of the FUD about firewalls and the
like...
The feedback that I have had from people using this technique is that the
apps that have had this code implemented experience dramatic reduction in
double postings to the point where they no longer exist.
And the code I posted is not making the basic application unavailable. It
just allows double-postings if javascript is not enabled which in practice
isn't that much when you consider the intersection of people who double
click and the people likely to have JS disabled.
For a heavily used site, I would recommend ultimately a better server-side
solution because the amount of time to develop and maintain a server side
solution is "worth it", but it's not as easy and quick to fix an app in
this respect as it is to add a quickie javascript fix for the short-term or
for an app that it's not worth spending more time on.
There's a lot of similar FUD about using cookies (not accepted on PDAs,
people scared of them, etc). Personally, I don't like to program using
cookies and I have my browser explicitly warn me of the cookie before
accepting (which does slow down my browsing experience but is most
interesting),, but the reality is that shedloads of sites use them to
enhance the user experience but don't make it a problem if they don't go
and use them.
Anyway, whatever. Happy New Year! :)
Speaking of which, I guess the non-use of Cookies and JavaScript would make
a great NY Resolution...
At 06:00 PM 1/4/2001 -0800, Randal L. Schwartz wrote:
> >>>>> "Gunther" == Gunther Birznieks <gu...@extropia.com> writes:
>
>Gunther> But I've also seen a lot of people use javascript to accomplish the
>Gunther> same thing as a quick fix. Few browsers don't support javascript. Of
>Gunther> the small amount that don't, the venn diagram merge of browsers that
>Gunther> don't do javascript and users with an itchy trigger finger is very
>Gunther> small. The advantage is that it's faster than mungling your own
>Gunther> server-side code with extra logic to prevent double posting.
>
>My browser "supports" Javascript, but has it turned off whenever I'm going
>to an unknown web page.
>
>Presuming that the CERT notices are being posted widely enough, there
>are demonstratably *more* people with Javascript turned off today than
>ever before.
>
>That means you can use Javascript to enhance the experience, but I'll
>come over and rip your throat out (if I knew your address) if you make
>it required for basic services.
>
>And don't forget the corporate firewalls that strip Javascript for
>security reasons. And the hundreds of new "net devices" showing up
>that understand HTTP and XHTML, but nothing about Javascript.
>
>Javascript. Just say no(t required).
>
>--
>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
><me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
>Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
>See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Javascript - just say no(t required)
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Gunther" == Gunther Birznieks <gu...@extropia.com> writes:
Gunther> But I've also seen a lot of people use javascript to accomplish the
Gunther> same thing as a quick fix. Few browsers don't support javascript. Of
Gunther> the small amount that don't, the venn diagram merge of browsers that
Gunther> don't do javascript and users with an itchy trigger finger is very
Gunther> small. The advantage is that it's faster than mungling your own
Gunther> server-side code with extra logic to prevent double posting.
My browser "supports" Javascript, but has it turned off whenever I'm going
to an unknown web page.
Presuming that the CERT notices are being posted widely enough, there
are demonstratably *more* people with Javascript turned off today than
ever before.
That means you can use Javascript to enhance the experience, but I'll
come over and rip your throat out (if I knew your address) if you make
it required for basic services.
And don't forget the corporate firewalls that strip Javascript for
security reasons. And the hundreds of new "net devices" showing up
that understand HTTP and XHTML, but nothing about Javascript.
Javascript. Just say no(t required).
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: getting rid of multiple identical http requests (bad users
double-clicking)
Posted by Stas Bekman <st...@stason.org>.
On Fri, 5 Jan 2001, Gunther Birznieks wrote:
> Sorry if this solution has been mentioned before (i didn't read the earlier
> parts of this thread), and I know it's not as perfect as a server-side
> solution...
>
> But I've also seen a lot of people use javascript to accomplish the same
> thing as a quick fix. Few browsers don't support javascript. Of the small
> amount that don't, the venn diagram merge of browsers that don't do
> javascript and users with an itchy trigger finger is very small. The
> advantage is that it's faster than mungling your own server-side code with
> extra logic to prevent double posting.
Nothing stops users from saving the form and resubmitting it without the
JS code. This may reduce the number of attempts, but it's a partial
solution and won't stop determined users.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: getting rid of multiple identical http requests (bad users
double-clicking)
Posted by Gunther Birznieks <gu...@extropia.com>.
Sorry if this solution has been mentioned before (i didn't read the earlier
parts of this thread), and I know it's not as perfect as a server-side
solution...
But I've also seen a lot of people use javascript to accomplish the same
thing as a quick fix. Few browsers don't support javascript. Of the small
amount that don't, the venn diagram merge of browsers that don't do
javascript and users with an itchy trigger finger is very small. The
advantage is that it's faster than mungling your own server-side code with
extra logic to prevent double posting.
Add this to the top of the form:
<SCRIPT LANGUAGE="JavaScript">
<!--
var clicks = 0;
function submitOnce() {
clicks ++;
if (clicks < 2) {
return true;
} else {
// alert("You have already clicked the submit button. " +
clicks + " clicks");
return false;
}
}
//-->
</SCRIPT>
And then just add the submitOnce() function to the submit event for the
<form> tag.
At 05:26 PM 1/4/01 -0800, Randal L. Schwartz wrote:
> >>>>> "Ed" == Ed Park <ep...@athenahealth.com> writes:
>
>Ed> Has anyone else thought about this?
>
>If you're generating the form on the fly (and who isn't, these days?),
>just spit a serial number into a hidden field. Then lock out two or
>more submissions with the same serial number, with a 24-hour retention
>of numbers you've generated. That'll keep 'em from hitting "back" and
>resubmitting too.
>
>To keep DOS attacks at a minimum, it should be a cryptographically
>secure MD5, to prevent others from lojacking your session.
>
>--
>Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
><me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
>Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
>See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: getting rid of multiple identical http requests (bad users double-clicking)
Posted by Les Mikesell <le...@home.com>.
----- Original Message -----
From: "Ed Park" <ep...@athenahealth.com>
To: <mo...@apache.org>
Sent: Thursday, January 04, 2001 6:52 PM
Subject: getting rid of multiple identical http requests (bad users
double-clicking)
> Does anyone out there have a clean, happy solution to the problem of users
> jamming on links & buttons? Analyzing our access logs, it is clear that it's
> relatively common for users to click 2,3,4+ times on a link if it doesn't
> come up right away. This not good for the system for obvious reasons.
The best solution is to make the page come up right away... If that isn't
possible, try to make at least something show up. If your page consists
of a big table the browser may be waiting until the closure to compute
the column widths before it can render anything.
> I can think of a few ways around this, but I was wondering if anyone else
> had come up with anything. Here are the avenues I'm exploring:
> 1. Implementing JavaScript disabling on the client side so that links become
> 'click-once' links.
> 2. Implement an MD5 hash of the request and store it on the server (e.g. in
> a MySQL server). When a new request comes in, check the MySQL server to see
> whether it matches an existing request and disallow as necessary. There
> might be some sort of timeout mechanism here, e.g. don't allow identical
> requests within the span of the last 20 seconds.
This might be worthwhile to trap duplicate postings, but unless your page
requires a vast amount of server work you might as well deliver it as
go to this much trouble.
Les Mikesell
lesmikesell@home.com
Re: getting rid of multiple identical http requests (bad users double-clicking)
Posted by "Randal L. Schwartz" <me...@stonehenge.com>.
>>>>> "Ed" == Ed Park <ep...@athenahealth.com> writes:
Ed> Has anyone else thought about this?
If you're generating the form on the fly (and who isn't, these days?),
just spit a serial number into a hidden field. Then lock out two or
more submissions with the same serial number, with a 24-hour retention
of numbers you've generated. That'll keep 'em from hitting "back" and
resubmitting too.
To keep DOS attacks at a minimum, it should be a cryptographically
secure MD5, to prevent others from lojacking your session.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<me...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!