|
|
Posted by Armando Padilla on 07/30/07 06:26
Yo,
Like everyone has mentioned, this has been around for ages. Here is one
of many solutions.
http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost
I first encountered this in my Java days, basically the way i went
around it was to create a unique form id for each form and place it
inside the users session. When the user tried to re-submit, logic would
check that a form session id was not already set. Once the user left the
page the session would null out. :-)
Armando Padilla
Jerry Stuckle wrote:
> Darko wrote:
>> On May 29, 12:55 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> ABC wrote:
>>>> Is there any article that you can direct me to? so that i can
>>>> understand the browser internal workings...
>>>> Any help on this appreciated
>>> None that I know of, unfortunately. But then I haven't looked.
>>> Although I do understand how the browser works, I've never found it
>>> necessary to code my pages.
>>>
>>> --
>>> ==================
>>> Remove the "x" from my email address
>>> Jerry Stuckle
>>> JDS Computer Training Corp.
>>> jstuck...@attglobal.net
>>> ==================
>>
>> This has been a common problem ever since first submit forms appeared
>> on the Internet. It has been solved in different ways, but each one of
>> them has its own issues. Recently, however, the Ajax technique has
>> become quite popular and it's, in my opinion, the perfect way (and the
>> best) to solve this kind of problem - let the submit button not have
>> "type=submit" but rather "type=button
>> onclick=send_post_data()" (pseudo code). Of course, you can then take
>> him to another page, if you want, or you can just update the current
>> page reflecting the status of his request. In this way, you can
>> manipulate whatever you want (hide the button after clicking, disable
>> it, whatever, or even let it be enabled but give a warning on the
>> second click etc), f5 doesn't mean "resubmit", and everything is
>> perfect. Of course, a cracker may always manually open the connection
>> to your processing script, but that's something that can't be overcome
>> in theory, thus not in practice neither, since you can't stop anyone
>> from calling your script. You can only stop accidental resubmits, and
>> that's the whole point.
>>
>
> Yes, that's one way of doing it. But the problem with that is it
> requires javascript to be active on the user's browser, and more and
> more users seem to be disabling javascript nowadays for security reasons.
>
>
>
Navigation:
[Reply to this message]
|